Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Thibault Raffaillac]

> 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/a-diabolical-game-for-a-diabolical-experiment
> . The game ended pretty well in my opinion:
> https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world
> .
Cool game for a first LD :) (I got till Europe and lost in the snowy mountains 
of Italy...)

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Dimitris Chloupis]

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-code-to-your-application.html


"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/a-diabolical-game-for-a-diabolical-experiment
. 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 

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Ronie Salgado]

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/a-diabolical-game-for-a-diabolical-experiment
. The game ended pretty well in my opinion:
https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world
.

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 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).


> 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.
>
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


2017-05-10 16:48 GMT-03:00 p...@highoctane.be :

> Or BeanShell
>
> http://www.beanshell.org/
>
> or Groovy
> https://zeroturnaround.com/rebellabs/scripting-your-java-
> application-with-groovy/
>
> 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/sequenceiq/ambari/shell/commands/BasicCommands.java
>
> 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 
> 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  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]
>>> > 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 

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[p...@highoctane.be]

Or BeanShell

http://www.beanshell.org/

or Groovy
https://zeroturnaround.com/rebellabs/scripting-your-java-application-with-groovy/

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/sequenceiq/ambari/shell/commands/BasicCommands.java

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 
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  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]
>> > 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
>> 

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[blake watson]

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  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]
> > 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: Re: Smalltalkers will, eventually, win. So
> says this old C++ programmer.
> 
>
> Sent from the Pharo Smalltalk Users mailing list archive
>  at Nabble.com.
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[nacho]

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, I really never used it.
just my 2c
best
Nacho




-
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: 
http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895p4946433.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[askoh]

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] 
>  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.

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Dimitris Chloupis]

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  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
>
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Pierce Ng]

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

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[p...@highoctane.be]

Let me add that I am perfectly happy with the system given the type and
size of applications I do write and maintain.

And having flow is #1 criteria for enjoying my work.

Phil

On Tue, May 9, 2017 at 6:59 PM, Stephan Eggermont  wrote:

> 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
>
>
>
>
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Göran Krampe]

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

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Steven R. Baker]

> 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
I talked to some folks about Strongtalk at StS a few years back, and
they told me that in order to achieve the speed improvements, they had
to throw away type information. Basically, they tried to prove that
static typing was faster, and proved the opposite.

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

-Steven


> (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  >:
>
> 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  > 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/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895.html
> 
> 
> Sent from the Pharo Smalltalk Users mailing list archive at
> Nabble.com.
>
>
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Stephane Ducasse]

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 
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 :
>
>> 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  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.
>>>
>>>
>>
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[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

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Dimitris Chloupis]

On Tue, May 9, 2017 at 10:02 AM askoh  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/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
There is no war, nowadays you can mix languages together with ease, pick
the one you prefer and do not make it a big deal.Personally I am
indifferent when it comes to types, do not care if I declare them or not.

Furthermore the choice of a language is 99% its libraries why bother with
the 1%. If the library you want is on Smalltalk you will pick Smalltalk
sadly C++ wins here with its vastness of libraries that have allowed such
an ugly language  to exist for so long.

I do not see why its necessary for the type to be embedded in the language
why not be meta data using a popular format like JSON and that will give
you the freedom to limit the types or not depending on the situation.

I love the smalltalk attitude of shifting the focus from the language to
the libraries and IDE. A gigantic syntax like C++ is a gigantic problem.

But to be fair C++ has come a long way, smart pointers have lifted the pain
of manual memory management, templates have helped with implementing
dynamic types. There is also a lot of talk of replacing the header system
with a module system like python. So C++ is definitely evolving. The game
engine I am using Unreal C++ has even further boosted the language not only
by using templates to offer dynamism but also offers manual GC and a
limited reflection system.

However the source of the popularity of C++ has been Microsoft and
Microsoft has been pushing a lot lately of its own language C# more
aggressively lately by open sourcing .NET and investing on cross platform
development.  C++ will of course keep being the choice of top performance
apps and libraries. When a new feature in C++ performance comes first
because that where the language focus on. We have a different goal.

So no I do not think Smalltalk will ever win on this one when it comes to
performance C++ has demonstrated that its syntax though very problematic
and quite annoying , it still is the No 1 choice.

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Raffaello Giulietti]

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 >:


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 > 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/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895.html


Sent from the Pharo Smalltalk Users mailing list archive at
Nabble.com.

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Esteban A. Maringolo]

2017-05-09 5:59 GMT-03:00 Sven Van Caekenberghe :
> Great article. Thanks for sharing.
>
> Not that I or most people here need convincing, but it is nice to see others 
> voicing this opinion.

+1

Not only the opinion, but it is good to see somebody with such
influence recognizing the merits of Smalltalk's approach.
I do find myself scratching my head when looking at "problems" other
developers have with their favorite toolset. Maybe I take too much for
granted; I notice it every time I have to leave the smooth land of a
live environment.

Nice article, thanks for sharing.

Regards!


Esteban A. Maringolo

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Eric Velten de Melo]

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 :

> 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  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.
>>
>>
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Ben Coman]

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  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/
> Smalltalkers-will-eventually-win-So-says-this-old-C-
> programmer-tp4945895.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Sven Van Caekenberghe]

Great article. Thanks for sharing.

Not that I or most people here need convincing, but it is nice to see others 
voicing this opinion.

> On 9 May 2017, at 08:49, askoh  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/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

[Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[askoh]

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/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.