I agree with Eric that some future programming environments will probably provide and encourage optional types + type inference. This doesn't necessarily contrast with late dynamic binding à la Smalltalk. If types are an entangled part of the language, like in virtually any statically typed programming language, it's hard to evolve them while maintaining backward compatibility with older code. This is one reason why a type system is perhaps best defined as an additional, optional component of a development environment. It is then up to the programmer to choose whether to use types and at which stage. Besides, optional pluggable type systems can evolve independently and perhaps even cohabit with others at the same time. With a sensible blend between type annotations and inference and between the language core and and a pluggable typing system, types should almost never hurt, while providing more benefits than costs. Sure, it all depends on how deeply they are enforced at all levels and phases of programming and how they are used. No doubts that in a complex and pervasive typing system as in C++, they are a real pain during the early phases of development and a burden at later stages, and make it harder to evolve software. When types are perceived simply as a means, not an end, they provide a really useful and well exploitable tool. Greetings Raffaello On 2017-05-09 16:17, Eric Velten de Melo wrote:

I think he forgets to mention Haskell, which is probably the reason behind the shift of Swift towards optional values (Option type in Scala, Maybe type in Haskell). You can't talk about modern type system without talking about Haskell, Monads and Algebraic Data Types (Maybe is a monad).

I don't believe the future is dynamic typing, I believe it is type inference and optional typing. There is no need to be radical about it. One great sadly forgotten example of this is Strongtalk, which was rumored to be the fastest implementation of Smalltalk ever made (I don't know how it compares to the latest Pharo VM, though) and included an optional strong type system (http://www.strongtalk.org/). Strongtalk team was bought by Sun before they could release the language and their advancements in virtual machine development were taken by the Java Virtual Machine. It is one of my dreams to see Strongtalk back into action or maybe a version of Self with optional typing, but I unfortunately lack the required skills and time to do so.

2017-05-09 10:26 GMT-03:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>:

Fantastic article. Very well rounded. I particularly liked "Meanwhile the Smalltalk programmers were scratching their heads wondering what the big deal was. You see, their language was also strongly typed; but their types were undeclared. In Smalltalk types were enforced at runtime."

and..."You see, the Smalltalk programmers had solved the missile problem in their own unique way. They invented a discipline. Today we call that discipline: Test Driven Development. ... You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?”

cheers -ben

On Tue, May 9, 2017 at 2:49 PM, askoh <askoh@askoh.com <mailto:askoh@askoh.com>> wrote:

This is a quote from Bob Martin of "Clean Code" fame. Enjoy, Aik-Siong Koh

http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html <http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html>

-- View this message in context: http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-pr... <http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-pr...> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

+1 and ;-) Am 09.05.2017 um 18:59 schrieb Stephan Eggermont:

On 09/05/17 16:17, Eric Velten de Melo wrote:

...

I think he forgets to mention Haskell, which is probably the reason behind the shift of Swift towards optional values (Option type in Scala, Maybe type in Haskell). You can't talk about modern type system without talking about Haskell, Monads and Algebraic Data Types (Maybe is a monad).

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.

Stephan

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

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+s1294792n4946404h48@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-pr... 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-pr... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Or BeanShell http://www.beanshell.org/ or Groovy https://zeroturnaround.com/rebellabs/scripting-your-java-application-with-gr... or Spring-Shell https://projects.spring.io/spring-shell/ Example app I am using (and extending) for Hadoop work: https://github.com/sequenceiq/ambari-shell When one looks inside a command, this is something easily achievable with pragmas. https://github.com/sequenceiq/ambari-shell/blob/master/src/main/java/com/seq... There is nothing extraordinary in these pieces of tech ("pas de quoi casser trois pattes à un canard" in French). But we need our own house in order on the CLI. GSoC time! Phil On Wed, May 10, 2017 at 7:38 PM, blake watson <dsblakewatson@gmail.com> wrote:

There is a Java REPL. You could Google that.

There's also a some kind of commercial hot/live compiler tool called "JRebel". Haven't tried it (don't code Java).

On Wed, May 10, 2017 at 4:29 AM, askoh <askoh@askoh.com> wrote:

...

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] <[hidden email] <http:///user/SendEmail.jtp?type=node&node=4946427&i=0>> 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] <http:///user/SendEmail.jtp?type=node&node=4946404&i=0>> 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 <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant...>

------------------------------ View this message in context: Re: Smalltalkers will, eventually, win. So says this old C++ programmer. <http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-pr...>

Sent from the Pharo Smalltalk Users mailing list archive <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com.

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?

10 minutes o_O wow, I can feel your suffering I do not know Java, I know it but only the very bare bones. What you should be looking for is any way of dynamic linking. Usually that means the ability to reload code on runtime, thats what DLLs are doing. Generally dynamic languages do this out of the box, for example python can reload its modules on runtime so live coding in python is very simple. Only a single command. Dynamic linking is a very basic functionality because its used for supporting scripting , plugins, addons , in short anything dynamic. I just googled "java dynamic code loading" which is what live coding is and this article came up , enjoy http://www.javaworld.com/article/2071777/design-patterns/add-dynamic-java-co... "Kilion, In Haskell (a language that I love, just as Smalltalk) you have the REPL. The workflow is, while you are working on the project, you periodically load that file into the REPL and check. After that you compile. Haskell works with a strong type inference feature, however most Haskellers will say that the best practice is to annotate all functions. Also if you are on macOS you have: http://haskellformac.com/ which is awesome, really a great piece of software. There was even a project called Kronos that was essentially the same as IPython but with a Haskell kernel I don't know the status of that project as of today" Problem with a REPL is that it makes me feel disconnected. I prefer working inside my source code directly and in an instant , no delays , no compromises and multi steps. hence why I love to live code. Plus why bother with a REPL when you can just live code ? I see no advantage but you can enlighten me :) "Hi kilon, Some weeks ago I tried the C live programming technique for the Ludum Dare. It works very well. For that occasion I wrote this short article https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world... . The game ended pretty well in my opinion: https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world ." Bookmarked to check when I log in my Windows (I use mainly macos) "I work for a video game company that is using Unreal Engine 4, we do not use the C++ live coding features. I do not like the way that they implemented live coding, and the bindings for their Blueprint visual language. We all hate the long compilation times of UE4, the fact that they use their own undocumented makefile system which is using a bunch C# files for building their project. We also do not like the fact that from time to time, we see that we are missing some #includes because of the unity builds that are done by the unreal build system (merging several .cpp before compiling them)." Yes the live coding feature of Unreal is far from impressive, do not know why they made it so limited and focused only for their editor. Also the inability to not be able to change blueprints run time is annoying too as is the build system. But I can still do my own way of live coding with C++ which is much more simple and much more flexible. "The biggest problem of these other language language is the lack of reflection information at runtime. The second other problem, is the lack of #become:, for swapping objects when their data layout changes. Elf files, PE files (.exe, .dll) and other executable formats are process images with a symbol table and relocation metadata. If the operating system allowed to modify in an easy way the symbol table of the current loaded process, it could be even cooler. In Linux, dlopen is implemented in terms of open() and mmap(). Best regards, Ronie" Reflection is indeed another beast and an area I have not touched yet. To be fair however, I rarely use reflection and I avoid meta programming. On the matter of symbol table its my understanding that DLLs come with their own symbol tables. It appears to me that you try to modify the executable , that's not my way of doing live coding with C++. Also to be clear about, my way of live coding is strictly Spartan. Which means that in the main loop the only thing that it should be in are: 1) the detection of changes to source code text files (usually checking the date and time format , plus size of the source code file should be enough) 2) the trigger of the relevant DLL compilation source code (simple commands passed to command line, this also means the compilation is automatic) 3) the reload of the DLL after compilation (again one command) 4) the capture of exception that will not allow the executable or the DLL to crash even if the DLL does something very bad ( a couple of lines of code) 5) and finally a singe pointer to a memory location that will be passed to DLLs (yeap a single one , it could be an array though if more flexibility is required for organisation puproses, again a couple of lines of code) In short only a dozen of lines of code will go in the executable that will be written once and never being changed. Coding will happen exclusively inside the source code of fhe DLLs and nowhere else. DLLs also will have to fully manage the memory. As you can imagine what we reload here is the entire DLL which means also that the DLL should be short if we do not want long compile times that defeats the purpose of live coding which turn it means big code will have to be broke down to many DLLs. But then we are Smalltalkers we love it brake down things to small stuff :D

This is why three years ago a convinced Pablo Tesone and Nicolas Passerini to work on a Type Inferencer for Pharo. Now the economic situation in argentina pushed Pablo to take another grant. And this is why we proposed as a topic to new guy in our team to work on this topic. Unfortunately the system did not give him the position. For the record marcus was involved in the gradual typing phd with chilean colleague (and we do not like gradual typing) worked on PlugType an optional pluggable typer for Squeak long time ago. So if people wants to get a typeInferencer for Pharo and have money to pay a phd let me know. Or you are gifted and like types and are looking for a PhD contact me :) Stef On Tue, May 9, 2017 at 4:17 PM, Eric Velten de Melo <ericvmelo@gmail.com> wrote:

I think he forgets to mention Haskell, which is probably the reason behind the shift of Swift towards optional values (Option type in Scala, Maybe type in Haskell). You can't talk about modern type system without talking about Haskell, Monads and Algebraic Data Types (Maybe is a monad).

I don't believe the future is dynamic typing, I believe it is type inference and optional typing. There is no need to be radical about it. One great sadly forgotten example of this is Strongtalk, which was rumored to be the fastest implementation of Smalltalk ever made (I don't know how it compares to the latest Pharo VM, though) and included an optional strong type system (http://www.strongtalk.org/). Strongtalk team was bought by Sun before they could release the language and their advancements in virtual machine development were taken by the Java Virtual Machine. It is one of my dreams to see Strongtalk back into action or maybe a version of Self with optional typing, but I unfortunately lack the required skills and time to do so.

2017-05-09 10:26 GMT-03:00 Ben Coman <btc@openinworld.com>:

...

Fantastic article. Very well rounded. I particularly liked "Meanwhile the Smalltalk programmers were scratching their heads wondering what the big deal was. You see, their language was also strongly typed; but their types were undeclared. In Smalltalk types were enforced at runtime."

and..."You see, the Smalltalk programmers had solved the missile problem in their own unique way. They invented a discipline. Today we call that discipline: Test Driven Development. ... You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?”

cheers -ben

On Tue, May 9, 2017 at 2:49 PM, askoh <askoh@askoh.com> wrote:

...

This is a quote from Bob Martin of "Clean Code" fame. Enjoy, Aik-Siong Koh

http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html

-- View this message in context: http://forum.world.st/Smalltal kers-will-eventually-win-So-says-this-old-C-programmer-tp4945895.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

On 09/05/17 21:22, Steven R. Baker wrote:

I'd like to have that confirmed; it would challenge "conventional wisdom" on static typing.

I don't recall details but I have read that no static type information was actually used for "speeding up", it was all PICs etc. So yes, an interesting fact. However - I don't think you can "prove" anything in this area. The fastest dynamic lang implementations like LuaJIT, V8 etc are still a fair factor away from the performance of C, C++, Nim, Rust (and similar statically typed langs and their compilers). In other words, the things you can optimize dynamically in an advanced runtime (say a tracing JIT like LuaJIT) haven't *yet* proven to overtake the raw advantage of all possible compile time optimizations. In theory a warmed up sufficiently advanced VM should beat statically compiled code - simply by the fact it has more information at hand. But... it hasn't been observed yet AFAIK. And even if it happens - in many areas where you need raw power you also have: - Memory requirements - Consistency in speed ...and a VM like say the JVM tend to fail hard on both accounts even if it can approach C++ speeds when sufficiently warmed up. regards, Göran