- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Sven Van Caekenberghe

I am all for a cleanup, the current situation is confusing. The basic #sum should be fast AND work for empty collections with 0 as starting element. I know why the #anyOne is used, and that use case should be preserved, but it is less common IMHO. > On 01 Dec 2015, at 09:38, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Max, > > Interesting results... > > replacing the #yourself in newSum: cuts the runtime by a factor of two. > using an [:x | x ] block cost 10% compared to a direct version of sum. > > So the fastest sum is: > > sum > ^ self > inject: > (self ifEmpty: [ ^ 0 ] ifNotEmpty: [ self anyOne ]) > into: [ :sum :each | sum + each ] > > And > > sum > ^ self sum: [:x | x ] > > is 10% slower. > > And > > sum > ^ self sum: #yourself > > is 100% slower (i.e. x2) > > It may be wise to avoid using #yourself for a block. > > Thierry > > > 2015-12-01 9:17 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > Hi guys, > > Collection defines #sum:, #detectSum: and #sumNumbers:, all of which accomplish the same (in principal) but with subtle differences: > > #sum: > - uses #inject:into: with #anyOne as the injected element and will thus fail for empty collections > > #detectSum: > - uses ânextValue + sumâ instead of âsum + nextValueâ which makes it a lot slower when dealing with large numbers (primitive fails and number conversion is necessary) > > #sumNumbers: > - same as #sum but doesnât fail for empty collections. Only good for numbers though. > > > Benchmarks: > > [ 100 timesRepeat: [ (1 to: 1000000) sum: #yourself ] ] timeToRun 18062 > [ 100 timesRepeat: [ (1 to: 1000000) detectSum: #yourself ] ] timeToRun 42391 > [ 100 timesRepeat: [ (1 to: 1000000) sumNumbers: #yourself ] ] timeToRun 18096 > > > > Can we settle for a single implementation? Such as (modified from #sumNumbers:): > > newSum: aBlock > ^ self > inject: (self > ifEmpty: [ 0 ] > ifNotEmpty: [ self anyOne ]) > into: [ :sum :each | sum + (aBlock value: each) ] > > This implementation combines the best of the three implementations I think. Benchmark: > > [ 100 timesRepeat: [ (1 to: 1000000) newSum: #yourself ] ] timeToRun 17955 > > > BTW, there is also the message #sum, which suffers from the same problem as #sum: (the implementation is basically a copy). #sum could be implemented as > > sum > ^ self sum: [ :x | x ] > > > As for the name for the new method, I suggest #sum:. > > Cheers, > Max >

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Peter Uhnak

The differences between #sum: and #sumNumbers: are well described in the respective method comments, but I agree that this may be a problem as most people will go for #sum: even for basic numeric collections. (And I personally got bit by this.) So maybe #sum: could adopt #sumNumbers: implementation, and the current #sum: implementation would be moved to #domainSum: (or some other appropriate name...)? As for #detectSum: I think this method has confusing name and is functionally duplicate to #sum:. The swapped arguments there may make sense when you overload #+, however the same thing can be achieved from the provided block ... On 12/01, Max Leske wrote: > Hi guys, > > Collection defines #sum:, #detectSum: and #sumNumbers:, all of which accomplish the same (in principal) but with subtle differences: > > #sum: > - uses #inject:into: with #anyOne as the injected element and will thus fail for empty collections > > #detectSum: > - uses ânextValue + sumâ instead of âsum + nextValueâ which makes it a lot slower when dealing with large numbers (primitive fails and number conversion is necessary) > > #sumNumbers: > - same as #sum but doesnât fail for empty collections. Only good for numbers though. > > > Benchmarks: > > [ 100 timesRepeat: [ (1 to: 1000000) sum: #yourself ] ] timeToRun 18062 > [ 100 timesRepeat: [ (1 to: 1000000) detectSum: #yourself ] ] timeToRun 42391 > [ 100 timesRepeat: [ (1 to: 1000000) sumNumbers: #yourself ] ] timeToRun 18096 > > > > Can we settle for a single implementation? Such as (modified from #sumNumbers:): > > newSum: aBlock > ^ self > inject: (self > ifEmpty: [ 0 ] > ifNotEmpty: [ self anyOne ]) > into: [ :sum :each | sum + (aBlock value: each) ] > > This implementation combines the best of the three implementations I think. Benchmark: > > [ 100 timesRepeat: [ (1 to: 1000000) newSum: #yourself ] ] timeToRun 17955 > > > BTW, there is also the message #sum, which suffers from the same problem as #sum: (the implementation is basically a copy). #sum could be implemented as > > sum > ^ self sum: [ :x | x ] > > > As for the name for the new method, I suggest #sum:. > > Cheers, > Max -- Peter

Dec. 1, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Thierry Goubier

Hi Max, Interesting results... replacing the #yourself in newSum: cuts the runtime by a factor of two. using an [:x | x ] block cost 10% compared to a direct version of sum. So the fastest sum is: sum ^ self inject: (self ifEmpty: [ ^ 0 ] ifNotEmpty: [ self anyOne ]) into: [ :sum :each | sum + each ] And sum ^ self sum: [:x | x ] is 10% slower. And sum ^ self sum: #yourself is 100% slower (i.e. x2) It may be wise to avoid using #yourself for a block. Thierry 2015-12-01 9:17 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > Hi guys, > > Collection defines #sum:, #detectSum: and #sumNumbers:, all of which > accomplish the same (in principal) but with subtle differences: > > #sum: > - uses #inject:into: with #anyOne as the injected element and will thus > fail for empty collections > > #detectSum: > - uses ânextValue + sumâ instead of âsum + nextValueâ which makes it a lot > slower when dealing with large numbers (primitive fails and number > conversion is necessary) > > #sumNumbers: > - same as #sum but doesnât fail for empty collections. Only good for > numbers though. > > > Benchmarks: > > [ 100 timesRepeat: [ (1 to: 1000000) sum: #yourself ] ] timeToRun 18062 > [ 100 timesRepeat: [ (1 to: 1000000) detectSum: #yourself ] ] timeToRun > 42391 > [ 100 timesRepeat: [ (1 to: 1000000) sumNumbers: #yourself ] ] timeToRun > 18096 > > > > Can we settle for a single implementation? Such as (modified from > #sumNumbers:): > > newSum: aBlock > ^ self > inject: (self > ifEmpty: [ 0 ] > ifNotEmpty: [ self anyOne ]) > into: [ :sum :each | sum + (aBlock value: each) ] > > This implementation combines the best of the three implementations I > think. Benchmark: > > [ 100 timesRepeat: [ (1 to: 1000000) newSum: #yourself ] ] timeToRun 17955 > > > BTW, there is also the message #sum, which suffers from the same problem > as #sum: (the implementation is basically a copy). #sum could be > implemented as > > sum > ^ self sum: [ :x | x ] > > > As for the name for the new method, I suggest #sum:. > > Cheers, > Max >

Dec. 1, 2015

#sum:, #detectSum:, #sumNumbers:

by Max Leske

Hi guys, Collection defines #sum:, #detectSum: and #sumNumbers:, all of which accomplish the same (in principal) but with subtle differences: #sum: - uses #inject:into: with #anyOne as the injected element and will thus fail for empty collections #detectSum: - uses ânextValue + sumâ instead of âsum + nextValueâ which makes it a lot slower when dealing with large numbers (primitive fails and number conversion is necessary) #sumNumbers: - same as #sum but doesnât fail for empty collections. Only good for numbers though. Benchmarks: [ 100 timesRepeat: [ (1 to: 1000000) sum: #yourself ] ] timeToRun 18062 [ 100 timesRepeat: [ (1 to: 1000000) detectSum: #yourself ] ] timeToRun 42391 [ 100 timesRepeat: [ (1 to: 1000000) sumNumbers: #yourself ] ] timeToRun 18096 Can we settle for a single implementation? Such as (modified from #sumNumbers:): newSum: aBlock ^ self inject: (self ifEmpty: [ 0 ] ifNotEmpty: [ self anyOne ]) into: [ :sum :each | sum + (aBlock value: each) ] This implementation combines the best of the three implementations I think. Benchmark: [ 100 timesRepeat: [ (1 to: 1000000) newSum: #yourself ] ] timeToRun 17955 BTW, there is also the message #sum, which suffers from the same problem as #sum: (the implementation is basically a copy). #sum could be implemented as sum ^ self sum: [ :x | x ] As for the name for the new method, I suggest #sum:. Cheers, Max

Dec. 1, 2015

dual-monitor pharo

by Peter Uhnak

Hi, has there been any effort done on running pharo on multiple monitors? Is it something that would require deep changes to VM? Can it be done image-side? Thanks, -- Peter

Dec. 1, 2015

Re: [Pharo-dev] Machine Learning algorithms

by HernÃ¡n Morales Durand

The package NaturalSmalltalk includes some supervised classifiers that you can try: NSBinaryNaiveBayesDocumentClassifier exampleBotchanOrShinran. NSNaiveBayesDocumentClassifier exampleBotchanOrShinran. NSTfidfDocumentClassifier exampleBotchanOrShinran. http://smalltalkhub.com/#!/~hernan/NaturalSmalltalk Cheers, HernÃ¡n 2015-11-30 20:08 GMT-03:00 KlÃ©risson PaixÃ£o <klerissonpaixao(a)gmail.com>: > Greetings! > > We're thinking to power up Pharo with some machine learning algorithms > (Naive Bayes, Random Forest and so on). I'm wondering if there is anything > done already? > > Thanks, > KlÃ©risson >

Dec. 1, 2015

Re: [Pharo-dev] Machine Learning algorithms

by serge.stinckwich＠gmail.com

Great initiative Klerisson ! This is better to talk on the pharo-users I guess. There is a project called SciSmalltalk where a lot of mathematics libraries are already available that might be useful for ML algorithms. Please join us on https://github.com/SergeStinckwich/SciSmalltalk Mailing list here: https://groups.google.com/forum/m/#!forum/scismalltalk Regards Sent from my iPhone > On 1 dÃ©c. 2015, at 00:08, KlÃ©risson PaixÃ£o <klerissonpaixao(a)gmail.com> wrote: > > Greetings! > > We're thinking to power up Pharo with some machine learning algorithms (Naive Bayes, Random Forest and so on). I'm wondering if there is anything done already? > > Thanks, > KlÃ©risson

Dec. 1, 2015

please name your thread [was: something else]

by Tudor Girba

Hi, I think we are not talking about the same email. In any case, please name you thread appropriately. And, we should remember that acting is the only thing that will push us further. Cheers, Tudor > On Dec 1, 2015, at 12:18 AM, EuanM <euanmee(a)gmail.com> wrote: > > Tudor, the email that you replied to, saying the discussion should be > closed down, was specifically about the impacts on our community and > how to leverage them. > > Welcoming is, as welcoming does. > > On 30 November 2015 at 11:20, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> Increasing the community is certainly important, and we welcome any action that anyone would want to undertake in this direction. >> >> However, talking about the future of Java does not fall in this category. >> >> Cheers, >> Doru >> >> >>> On Nov 30, 2015, at 4:44 AM, EuanM <euanmee(a)gmail.com> wrote: >>> >>> We also need to concentrate on building our community. >>> >>> We build a better platform faster if we have more people. >>> >>> We build a more valuable platform if we have a wider range of valuable >>> use cases to target. >>> >>> Unless and until we hit a critical mass of people joining our >>> community, we *need* to spend some of our focus on community-building. >>> >>> Part of great is being able to build things to sufficient completeness >>> *and* keep them in working order over the long haul. This is easier >>> with more contributors. >>> >>> On 27 November 2015 at 21:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> Hello everyone, >>>> >>>> Please stop this thread on this mailing list. We need to focus on building a great platform. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Nov 27, 2015, at 10:05 PM, EuanM <euanmee(a)gmail.com> wrote: >>>>> >>>>> First of all - is this true? Where can we read about it? >>>>> >>>>> I cannot find anything about this at >>>>> https://www.oracle.com/search/press >>>>> >>>>> ======================================= >>>>> >>>>> If Oracle did make this statement, then what people have said so far >>>>> is true. BUT... >>>>> >>>>> Java got about 40% of its initial momentum from IBM dumping VisualAge >>>>> and putting all their resources into Java. >>>>> >>>>> Oracle are targetting this move at IBM more than anyone else. >>>>> >>>>> IBM will start to think about how to migrate from Java - as Oracle are >>>>> telling them they will have to. (It's OUR bat and its OUR ball, and >>>>> no-one else can play with it. Not even the Java Community). And >>>>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >>>>> expect the licence-fee income for JREs is small. >>>>> >>>>> Oracle are doing one of two things - announcing that Java is for sale >>>>> to device providers - phones (Google is the obvious buyer) or the >>>>> impending Internet of Things (which was what Java was designed for >>>>> originally) or announcing that no-one making an internet of things >>>>> offering should consider Java. >>>>> >>>>> Yes, things live on and on in a kind of zombie state. So yes, things >>>>> live on as long as their ecosystem does. And they gently wither and >>>>> their ecosystem withers is a long slow drawn out spiral. Which is why >>>>> we still have Cobol. >>>>> >>>>> People and organisations tend to move from one technology to another >>>>> in an incremental fashion. Swapping a little bit here, and a little >>>>> bit there. >>>>> >>>>> The new target platforms are ones which >>>>> 1) look like they have longevity, and >>>>> 2) have a migration pathway that provides incremental steps. >>>>> >>>>> Offering a compelling advantage is good - but only if the steps 1) >>>>> and 2) are catered to. >>>>> >>>>> IBM VisualAge Smalltalk is still robust, commercially available >>>>> software, and VisualStudio and Gemstone continue to represent >>>>> Smalltalk out to the big world of corporate development. >>>>> >>>>> So that's a start. >>>>> >>>>> Say only 5% of the Java world moves away from Java each year, as a >>>>> result of this announcement. >>>>> >>>>> We *should* wish to take advantage of this announcement. >>>>> >>>>> After all, think what difference having even 0.01% of the world's Java >>>>> coders moving to Smalltalk would make. How could we help that >>>>> happen? >>>>> >>>>> Think what it would be like to have thought-leaders like Kent Beck and >>>>> Ward Cunningham back in the Smalltalk fold. How could we help that >>>>> happen? >>>>> >>>>> Think what it would be like to get back all the universities who moved >>>>> from teaching OO concepts using Smalltalk into teaching them via Java. >>>>> We now know almost all the ones using Smalltalk as a teaching language >>>>> by name. Does anyone know even how many universities teach OO via >>>>> Java? What would it be like if 5% of those universities moved to >>>>> Smalltalk each year. How could we help that happen? >>>>> >>>>> Next - do we have any big brained thinkers who can see specific ways >>>>> we can improve interoperation between Java facilities and libraries >>>>> and the Smalltalks? For the next 12 months, we should work on Java >>>>> integration, rather than C++ integration. We should identify the >>>>> three best things for us to do in this regard, and make them polished >>>>> and compelling. Who is in a position to help that happen? >>>>> >>>>> The final way we can take advantage help the maximum number of people >>>>> find their way to us is to present a united community front to the >>>>> outside world. In the same way I am both a European and a Scot, we >>>>> need to be Smalltalkers *and*members of our individual >>>>> Smalltalk-platform communities. >>>>> >>>>> How can we help make that happen? >>>>> >>>>> This is not a silver bullet. It's going to cause a long-term trend in >>>>> events, not a sudden abrupt change. But it will have a real, if >>>>> gradual effect. (assuming that >>>>> >>>>> Equally, it is not something we should ignore. It is something we >>>>> should make use of. We need to put effort into raising our profile >>>>> over the next 6 months. >>>>> >>>>> On 25 November 2015 at 19:51, Casimiro - GMAIL >>>>> <casimiro.barreto(a)gmail.com> wrote: >>>>>> Em 25-11-2015 17:21, Nicolas Anquetil escreveu: >>>>>> >>>>>> >>>>>> >>>>>> On 25/11/2015 19:55, Jimmie Houchin wrote: >>>>>> >>>>>> Much truth in what you say. However, what Oracle choose to invest its money, >>>>>> time, personnel resource into Java does affect its present and future. It >>>>>> has a great affect. But it isn't the whole story. Java has enough momentum >>>>>> in what already exists in the language and vm and what has been release >>>>>> under its license, for businesses to keep going for some time with only what >>>>>> currently exists. >>>>>> >>>>>> Cobol is still alive (and well) after > 50 years. >>>>>> You can expect Java programmers to find jobs for many years yet to come >>>>>> :-) >>>>>> >>>>>> nicolas >>>>>> >>>>>> -- >>>>>> Nicolas Anquetil >>>>>> RMod team -- Inria Lille >>>>>> >>>>>> 1st: Java is extremely profitable. Each android phone, each android TV, each >>>>>> android embedded system pays copyrights to Oracle. >>>>>> 2nd: Much of current cloud infrastructure depends on java. >>>>>> 3rd: Java is already obsolete, like Frotran, Cobol, C, C++. It will continue >>>>>> to be used by same reasons these languages are used. >>>>>> >>>>>> IMHO, discussing java is not profitable. Better to discuss things to be than >>>>>> talk about things that already happened. >>>>>> >>>>>> casimiro >>>>>> >>>>>> -- >>>>>> The information contained in this message is confidential and intended to >>>>>> the recipients specified in the headers. If you received this message by >>>>>> error, notify the sender immediately. The unauthorized use, disclosure, copy >>>>>> or alteration of this message are strictly forbidden and subjected to civil >>>>>> and criminal sanctions. >>>>>> >>>>>> == >>>>>> >>>>>> This email may be signed using PGP key ID: 0x4134A417 >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Reasonable is what we are accustomed with." >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> > -- www.tudorgirba.com "One cannot do more than one can do."

Nov. 30, 2015

Re: [Pharo-dev] Java Future

by EuanM

Tudor, the email that you replied to, saying the discussion should be closed down, was specifically about the impacts on our community and how to leverage them. Welcoming is, as welcoming does. On 30 November 2015 at 11:20, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Increasing the community is certainly important, and we welcome any action that anyone would want to undertake in this direction. > > However, talking about the future of Java does not fall in this category. > > Cheers, > Doru > > >> On Nov 30, 2015, at 4:44 AM, EuanM <euanmee(a)gmail.com> wrote: >> >> We also need to concentrate on building our community. >> >> We build a better platform faster if we have more people. >> >> We build a more valuable platform if we have a wider range of valuable >> use cases to target. >> >> Unless and until we hit a critical mass of people joining our >> community, we *need* to spend some of our focus on community-building. >> >> Part of great is being able to build things to sufficient completeness >> *and* keep them in working order over the long haul. This is easier >> with more contributors. >> >> On 27 November 2015 at 21:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hello everyone, >>> >>> Please stop this thread on this mailing list. We need to focus on building a great platform. >>> >>> Cheers, >>> Doru >>> >>> >>>> On Nov 27, 2015, at 10:05 PM, EuanM <euanmee(a)gmail.com> wrote: >>>> >>>> First of all - is this true? Where can we read about it? >>>> >>>> I cannot find anything about this at >>>> https://www.oracle.com/search/press >>>> >>>> ======================================= >>>> >>>> If Oracle did make this statement, then what people have said so far >>>> is true. BUT... >>>> >>>> Java got about 40% of its initial momentum from IBM dumping VisualAge >>>> and putting all their resources into Java. >>>> >>>> Oracle are targetting this move at IBM more than anyone else. >>>> >>>> IBM will start to think about how to migrate from Java - as Oracle are >>>> telling them they will have to. (It's OUR bat and its OUR ball, and >>>> no-one else can play with it. Not even the Java Community). And >>>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >>>> expect the licence-fee income for JREs is small. >>>> >>>> Oracle are doing one of two things - announcing that Java is for sale >>>> to device providers - phones (Google is the obvious buyer) or the >>>> impending Internet of Things (which was what Java was designed for >>>> originally) or announcing that no-one making an internet of things >>>> offering should consider Java. >>>> >>>> Yes, things live on and on in a kind of zombie state. So yes, things >>>> live on as long as their ecosystem does. And they gently wither and >>>> their ecosystem withers is a long slow drawn out spiral. Which is why >>>> we still have Cobol. >>>> >>>> People and organisations tend to move from one technology to another >>>> in an incremental fashion. Swapping a little bit here, and a little >>>> bit there. >>>> >>>> The new target platforms are ones which >>>> 1) look like they have longevity, and >>>> 2) have a migration pathway that provides incremental steps. >>>> >>>> Offering a compelling advantage is good - but only if the steps 1) >>>> and 2) are catered to. >>>> >>>> IBM VisualAge Smalltalk is still robust, commercially available >>>> software, and VisualStudio and Gemstone continue to represent >>>> Smalltalk out to the big world of corporate development. >>>> >>>> So that's a start. >>>> >>>> Say only 5% of the Java world moves away from Java each year, as a >>>> result of this announcement. >>>> >>>> We *should* wish to take advantage of this announcement. >>>> >>>> After all, think what difference having even 0.01% of the world's Java >>>> coders moving to Smalltalk would make. How could we help that >>>> happen? >>>> >>>> Think what it would be like to have thought-leaders like Kent Beck and >>>> Ward Cunningham back in the Smalltalk fold. How could we help that >>>> happen? >>>> >>>> Think what it would be like to get back all the universities who moved >>>> from teaching OO concepts using Smalltalk into teaching them via Java. >>>> We now know almost all the ones using Smalltalk as a teaching language >>>> by name. Does anyone know even how many universities teach OO via >>>> Java? What would it be like if 5% of those universities moved to >>>> Smalltalk each year. How could we help that happen? >>>> >>>> Next - do we have any big brained thinkers who can see specific ways >>>> we can improve interoperation between Java facilities and libraries >>>> and the Smalltalks? For the next 12 months, we should work on Java >>>> integration, rather than C++ integration. We should identify the >>>> three best things for us to do in this regard, and make them polished >>>> and compelling. Who is in a position to help that happen? >>>> >>>> The final way we can take advantage help the maximum number of people >>>> find their way to us is to present a united community front to the >>>> outside world. In the same way I am both a European and a Scot, we >>>> need to be Smalltalkers *and*members of our individual >>>> Smalltalk-platform communities. >>>> >>>> How can we help make that happen? >>>> >>>> This is not a silver bullet. It's going to cause a long-term trend in >>>> events, not a sudden abrupt change. But it will have a real, if >>>> gradual effect. (assuming that >>>> >>>> Equally, it is not something we should ignore. It is something we >>>> should make use of. We need to put effort into raising our profile >>>> over the next 6 months. >>>> >>>> On 25 November 2015 at 19:51, Casimiro - GMAIL >>>> <casimiro.barreto(a)gmail.com> wrote: >>>>> Em 25-11-2015 17:21, Nicolas Anquetil escreveu: >>>>> >>>>> >>>>> >>>>> On 25/11/2015 19:55, Jimmie Houchin wrote: >>>>> >>>>> Much truth in what you say. However, what Oracle choose to invest its money, >>>>> time, personnel resource into Java does affect its present and future. It >>>>> has a great affect. But it isn't the whole story. Java has enough momentum >>>>> in what already exists in the language and vm and what has been release >>>>> under its license, for businesses to keep going for some time with only what >>>>> currently exists. >>>>> >>>>> Cobol is still alive (and well) after > 50 years. >>>>> You can expect Java programmers to find jobs for many years yet to come >>>>> :-) >>>>> >>>>> nicolas >>>>> >>>>> -- >>>>> Nicolas Anquetil >>>>> RMod team -- Inria Lille >>>>> >>>>> 1st: Java is extremely profitable. Each android phone, each android TV, each >>>>> android embedded system pays copyrights to Oracle. >>>>> 2nd: Much of current cloud infrastructure depends on java. >>>>> 3rd: Java is already obsolete, like Frotran, Cobol, C, C++. It will continue >>>>> to be used by same reasons these languages are used. >>>>> >>>>> IMHO, discussing java is not profitable. Better to discuss things to be than >>>>> talk about things that already happened. >>>>> >>>>> casimiro >>>>> >>>>> -- >>>>> The information contained in this message is confidential and intended to >>>>> the recipients specified in the headers. If you received this message by >>>>> error, notify the sender immediately. The unauthorized use, disclosure, copy >>>>> or alteration of this message are strictly forbidden and subjected to civil >>>>> and criminal sanctions. >>>>> >>>>> == >>>>> >>>>> This email may be signed using PGP key ID: 0x4134A417 >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Reasonable is what we are accustomed with." >>> >>> >> > > -- > www.tudorgirba.com > > "Presenting is storytelling." > >

Nov. 30, 2015

Re: [Pharo-dev] Java Future

by EuanM

We also miss a critical mass of warm bodies. Funing is very nice, don;t get me wrong. But in the absence of funding we need to be even more smart about gaining, and retaining enthusiast volunteers. On 30 November 2015 at 20:45, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > We do need more ease of integration with other software. > > * 64 bit. > * OS Process made easier. > * FFI not requiring a PhD > * Being able to use Pharo with normal text based tools (like mount an image > like a filesystem). > * Full integration with trendy tools. e.g. MongoTalk missing GridFS, > sharding, HA. > > These things are moving forward. > > I am pissed that Julia got $600 000 and we are struggling due to cash > issues. > > We do not miss brainpower. We miss being able to focus on progress because > we can't fund it well enough. > > Phil > > > > On Nov 30, 2015 12:21 PM, "Tudor Girba" <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> Increasing the community is certainly important, and we welcome any action >> that anyone would want to undertake in this direction. >> >> However, talking about the future of Java does not fall in this category. >> >> Cheers, >> Doru >> >> >> > On Nov 30, 2015, at 4:44 AM, EuanM <euanmee(a)gmail.com> wrote: >> > >> > We also need to concentrate on building our community. >> > >> > We build a better platform faster if we have more people. >> > >> > We build a more valuable platform if we have a wider range of valuable >> > use cases to target. >> > >> > Unless and until we hit a critical mass of people joining our >> > community, we *need* to spend some of our focus on community-building. >> > >> > Part of great is being able to build things to sufficient completeness >> > *and* keep them in working order over the long haul. This is easier >> > with more contributors. >> > >> > On 27 November 2015 at 21:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hello everyone, >> >> >> >> Please stop this thread on this mailing list. We need to focus on >> >> building a great platform. >> >> >> >> Cheers, >> >> Doru >> >> >> >> >> >>> On Nov 27, 2015, at 10:05 PM, EuanM <euanmee(a)gmail.com> wrote: >> >>> >> >>> First of all - is this true? Where can we read about it? >> >>> >> >>> I cannot find anything about this at >> >>> https://www.oracle.com/search/press >> >>> >> >>> ======================================= >> >>> >> >>> If Oracle did make this statement, then what people have said so far >> >>> is true. BUT... >> >>> >> >>> Java got about 40% of its initial momentum from IBM dumping VisualAge >> >>> and putting all their resources into Java. >> >>> >> >>> Oracle are targetting this move at IBM more than anyone else. >> >>> >> >>> IBM will start to think about how to migrate from Java - as Oracle are >> >>> telling them they will have to. (It's OUR bat and its OUR ball, and >> >>> no-one else can play with it. Not even the Java Community). And >> >>> IBM's coders do not pay for Java, Eclipse users do not pay for Java. I >> >>> expect the licence-fee income for JREs is small. >> >>> >> >>> Oracle are doing one of two things - announcing that Java is for sale >> >>> to device providers - phones (Google is the obvious buyer) or the >> >>> impending Internet of Things (which was what Java was designed for >> >>> originally) or announcing that no-one making an internet of things >> >>> offering should consider Java. >> >>> >> >>> Yes, things live on and on in a kind of zombie state. So yes, things >> >>> live on as long as their ecosystem does. And they gently wither and >> >>> their ecosystem withers is a long slow drawn out spiral. Which is why >> >>> we still have Cobol. >> >>> >> >>> People and organisations tend to move from one technology to another >> >>> in an incremental fashion. Swapping a little bit here, and a little >> >>> bit there. >> >>> >> >>> The new target platforms are ones which >> >>> 1) look like they have longevity, and >> >>> 2) have a migration pathway that provides incremental steps. >> >>> >> >>> Offering a compelling advantage is good - but only if the steps 1) >> >>> and 2) are catered to. >> >>> >> >>> IBM VisualAge Smalltalk is still robust, commercially available >> >>> software, and VisualStudio and Gemstone continue to represent >> >>> Smalltalk out to the big world of corporate development. >> >>> >> >>> So that's a start. >> >>> >> >>> Say only 5% of the Java world moves away from Java each year, as a >> >>> result of this announcement. >> >>> >> >>> We *should* wish to take advantage of this announcement. >> >>> >> >>> After all, think what difference having even 0.01% of the world's Java >> >>> coders moving to Smalltalk would make. How could we help that >> >>> happen? >> >>> >> >>> Think what it would be like to have thought-leaders like Kent Beck and >> >>> Ward Cunningham back in the Smalltalk fold. How could we help that >> >>> happen? >> >>> >> >>> Think what it would be like to get back all the universities who moved >> >>> from teaching OO concepts using Smalltalk into teaching them via Java. >> >>> We now know almost all the ones using Smalltalk as a teaching language >> >>> by name. Does anyone know even how many universities teach OO via >> >>> Java? What would it be like if 5% of those universities moved to >> >>> Smalltalk each year. How could we help that happen? >> >>> >> >>> Next - do we have any big brained thinkers who can see specific ways >> >>> we can improve interoperation between Java facilities and libraries >> >>> and the Smalltalks? For the next 12 months, we should work on Java >> >>> integration, rather than C++ integration. We should identify the >> >>> three best things for us to do in this regard, and make them polished >> >>> and compelling. Who is in a position to help that happen? >> >>> >> >>> The final way we can take advantage help the maximum number of people >> >>> find their way to us is to present a united community front to the >> >>> outside world. In the same way I am both a European and a Scot, we >> >>> need to be Smalltalkers *and*members of our individual >> >>> Smalltalk-platform communities. >> >>> >> >>> How can we help make that happen? >> >>> >> >>> This is not a silver bullet. It's going to cause a long-term trend in >> >>> events, not a sudden abrupt change. But it will have a real, if >> >>> gradual effect. (assuming that >> >>> >> >>> Equally, it is not something we should ignore. It is something we >> >>> should make use of. We need to put effort into raising our profile >> >>> over the next 6 months. >> >>> >> >>> On 25 November 2015 at 19:51, Casimiro - GMAIL >> >>> <casimiro.barreto(a)gmail.com> wrote: >> >>>> Em 25-11-2015 17:21, Nicolas Anquetil escreveu: >> >>>> >> >>>> >> >>>> >> >>>> On 25/11/2015 19:55, Jimmie Houchin wrote: >> >>>> >> >>>> Much truth in what you say. However, what Oracle choose to invest its >> >>>> money, >> >>>> time, personnel resource into Java does affect its present and >> >>>> future. It >> >>>> has a great affect. But it isn't the whole story. Java has enough >> >>>> momentum >> >>>> in what already exists in the language and vm and what has been >> >>>> release >> >>>> under its license, for businesses to keep going for some time with >> >>>> only what >> >>>> currently exists. >> >>>> >> >>>> Cobol is still alive (and well) after > 50 years. >> >>>> You can expect Java programmers to find jobs for many years yet to >> >>>> come >> >>>> :-) >> >>>> >> >>>> nicolas >> >>>> >> >>>> -- >> >>>> Nicolas Anquetil >> >>>> RMod team -- Inria Lille >> >>>> >> >>>> 1st: Java is extremely profitable. Each android phone, each android >> >>>> TV, each >> >>>> android embedded system pays copyrights to Oracle. >> >>>> 2nd: Much of current cloud infrastructure depends on java. >> >>>> 3rd: Java is already obsolete, like Frotran, Cobol, C, C++. It will >> >>>> continue >> >>>> to be used by same reasons these languages are used. >> >>>> >> >>>> IMHO, discussing java is not profitable. Better to discuss things to >> >>>> be than >> >>>> talk about things that already happened. >> >>>> >> >>>> casimiro >> >>>> >> >>>> -- >> >>>> The information contained in this message is confidential and >> >>>> intended to >> >>>> the recipients specified in the headers. If you received this message >> >>>> by >> >>>> error, notify the sender immediately. The unauthorized use, >> >>>> disclosure, copy >> >>>> or alteration of this message are strictly forbidden and subjected to >> >>>> civil >> >>>> and criminal sanctions. >> >>>> >> >>>> == >> >>>> >> >>>> This email may be signed using PGP key ID: 0x4134A417 >> >>> >> >> >> >> -- >> >> www.tudorgirba.com >> >> >> >> "Reasonable is what we are accustomed with." >> >> >> >> >> > >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >>

Nov. 30, 2015