Hi!
Just to share some thought. I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of): self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error I have to shut down the method #validateShouldntException: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218
it looks unsuspicous until the moment you try understand such a failing assertion. On 2013-10-21, at 23:42, Alexandre Bergel <[hidden email]> wrote: > Hi! > > Just to share some thought. > I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of): > > self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error > > I have to shut down the method #validateShouldntException: > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > signature.asc (457 bytes) Download Attachment |
Instead of using shouldnt:raise:, you can simply remove the assertion, as in:
-=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error -=-=-=-=-=-=-=-=-= || V -=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing view raw drawOn: tracingCanvas -=-=-=-=-=-=-=-=-= With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure. I read your post and I kind of agree. I will fix my tests then. Alexandre On Oct 22, 2013, at 12:08 AM, Camillo Bruni <[hidden email]> wrote: > see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 > it looks unsuspicous until the moment you try understand such a failing assertion. > > On 2013-10-21, at 23:42, Alexandre Bergel <[hidden email]> wrote: > >> Hi! >> >> Just to share some thought. >> I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of): >> >> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error >> >> I have to shut down the method #validateShouldntException: >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
On 2013-10-22, at 00:20, Alexandre Bergel <[hidden email]> wrote: > Instead of using shouldnt:raise:, you can simply remove the assertion, as in: > > -=-=-=-=-=-=-=-=-= > testNoErrorWhenDrawing > self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error > -=-=-=-=-=-=-=-=-= > > || > V > > -=-=-=-=-=-=-=-=-= > testNoErrorWhenDrawing > view raw drawOn: tracingCanvas > -=-=-=-=-=-=-=-=-= > > With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure. does not make much sense. It makes a little bit more sense when using a specific Error, and it makes sense when testing for Notifications, which would go otherwise unnoticed. Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets you use anything else. > I read your post and I kind of agree. > I will fix my tests then. nice :) signature.asc (457 bytes) Download Attachment |
In reply to this post by Camillo Bruni-3
I will add a discussion to the SUnit Chapter about this point.
Stef On Oct 22, 2013, at 12:08 AM, Camillo Bruni <[hidden email]> wrote: > see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 > it looks unsuspicous until the moment you try understand such a failing assertion. > > On 2013-10-21, at 23:42, Alexandre Bergel <[hidden email]> wrote: > >> Hi! >> >> Just to share some thought. >> I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of): >> >> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error >> >> I have to shut down the method #validateShouldntException: >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > |
In reply to this post by Camillo Bruni-3
In Seaside, there are a couple of tests that now fail because of this change.
Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho. I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end. I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause. Johan On 22 Oct 2013, at 00:26, Camillo Bruni <[hidden email]> wrote: > > On 2013-10-22, at 00:20, Alexandre Bergel <[hidden email]> wrote: > >> Instead of using shouldnt:raise:, you can simply remove the assertion, as in: >> >> -=-=-=-=-=-=-=-=-= >> testNoErrorWhenDrawing >> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error >> -=-=-=-=-=-=-=-=-= >> >> || >> V >> >> -=-=-=-=-=-=-=-=-= >> testNoErrorWhenDrawing >> view raw drawOn: tracingCanvas >> -=-=-=-=-=-=-=-=-= >> >> With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure. > > Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors > does not make much sense. It makes a little bit more sense when using a specific Error, and it > makes sense when testing for Notifications, which would go otherwise unnoticed. > > Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets > you use anything else. > >> I read your post and I kind of agree. >> I will fix my tests then. > > nice :) |
On 2013-10-22, at 09:46, Johan Brichau <[hidden email]> wrote:
> In Seaside, there are a couple of tests that now fail because of this change. > > Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho. That's not true, that is the default behavior that you test for not Errors. I mean every code that is run must work and testing that it does not raise and Error is duplicated efforts. As I said, checking for any other error makes somehow sense, but not for Error itself. Because that basically means that you ignore what the test does since you are not specific at all. The test framework takes already care of that part, if you have an error the test fails. I think that is the goal. I do not understand why you would have to explain this to the user of the tests, since for him the result does not change. Yes it is red instead of yellow, but does that matter? I mean you just transformed at will an error into an assertion failure, to me this sounds very bogus. Just because you transform the error to an assertion, you did not anticipated anything, since you cannot be sure at all where the error happened, since you do not test for an explicit error. On the other hand if you call a method that is very small to check if it really works, you know which errors are signaled and you test explicitly for those. I think I can come up with a tree transformation rule to go from #shouldnt:raise:Error to a refactored version that even includes a comment. > I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end. > I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause. But if you just use the expression directly, the debugger pops up in the place where the error was signaled. Not somewhere in deep in the assertion framework. Furthermore if you run the test under jenkins you will get no reasonable feedback (yes this should be changed as well). Just try to debug the following statement in a test: self shouldnt: [ 0/0 ] raise: Error vs. 0/0. Of course we can change it back at some point, but I haven't heard a solid reason in favor of shouldnt:raise:Error. > Johan > > On 22 Oct 2013, at 00:26, Camillo Bruni <[hidden email]> wrote: > >> >> On 2013-10-22, at 00:20, Alexandre Bergel <[hidden email]> wrote: >> >>> Instead of using shouldnt:raise:, you can simply remove the assertion, as in: >>> >>> -=-=-=-=-=-=-=-=-= >>> testNoErrorWhenDrawing >>> self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error >>> -=-=-=-=-=-=-=-=-= >>> >>> || >>> V >>> >>> -=-=-=-=-=-=-=-=-= >>> testNoErrorWhenDrawing >>> view raw drawOn: tracingCanvas >>> -=-=-=-=-=-=-=-=-= >>> >>> With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure. >> >> Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors >> does not make much sense. It makes a little bit more sense when using a specific Error, and it >> makes sense when testing for Notifications, which would go otherwise unnoticed. >> >> Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets >> you use anything else. >> >>> I read your post and I kind of agree. >>> I will fix my tests then. >> >> nice :) > > signature.asc (457 bytes) Download Attachment |
On 22 October 2013 10:02, Camillo Bruni <[hidden email]> wrote:
+1 'shouldn't raise' is bogus and as you said, it is default expectation for any code you run that it doesn't throws any errors. (that's why exceptions called so and that's why error is exception). i can understand why i would want to use 'should raise' to check that my code throws appropriate error when i using wrong data etc.. but not this one. As I said, checking for any other error makes -- Best regards, Igor Stasenko. |
In reply to this post by Camillo Bruni-3
On 22.10.13 00:08, Camillo Bruni wrote:
> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 > it looks unsuspicous until the moment you try understand such a failing assertion. This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way. This only adds code who's sole purpose is to break people's existing code. If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule. Cheers Philippe |
While I agree that we shouldn’t unnecessary make life more difficult for external frameworks/libraries when that can be avoided, we do have to reserve the right to be able to make changes that break things.
Like with #includesSubstring: the actual intention of the change is valid and sound, but the process could have been smoother. Issue 11876 does have a point and it does simplify the system, IMHO. On 24 Oct 2013, at 08:17, Philippe Marschall <[hidden email]> wrote: > On 22.10.13 00:08, Camillo Bruni wrote: >> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 >> it looks unsuspicous until the moment you try understand such a failing assertion. > > This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way. > > This only adds code who's sole purpose is to break people's existing code. > > If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule. > > Cheers > Philippe > > |
In reply to this post by Philippe Marschall-2
On 24 October 2013 08:17, Philippe Marschall <[hidden email]> wrote:
Running SLint over tests? I could agree the working code should be checked for rules.. but tests? Useful, to some pedantic souls i guess , but not me :) But anyways, i agree with you, we should not dictate what is 'best' rules and 'how you should do the coding', we shall let people discover own and let them shoot into their own foot, if they insisting to. Cheers -- Best regards, Igor Stasenko. |
On 24.10.13 15:24, Igor Stasenko wrote:
> > > > On 24 October 2013 08:17, Philippe Marschall > <[hidden email] > <mailto:[hidden email]>> wrote: > > On 22.10.13 00:08, Camillo Bruni wrote: > > see my long explanation here > https://pharo.fogbugz.com/__default.asp?11876#87218 > <https://pharo.fogbugz.com/default.asp?11876#87218> > it looks unsuspicous until the moment you try understand such a > failing assertion. > > > This isn't moving Pharo foward. This doesn't make the system any > more flexible, adaptable, modular or malleable. This doesn't make > the system any easier to maintain. This doesn't make the system any > smaller, faster, scalable or secure. This doesn't make the system > any easier to maintain. This doesn't make life easier for anybody > developing Pharo or using Pharo. This doesn't improve Pharo in any way. > > This only adds code who's sole purpose is to break people's existing > code. > > If you disagree with such a way of writing tests then the right > solution IMHO is to write a SLint rule. > > > Running SLint over tests? I could agree the working code should be > checked for rules.. but tests? Yes. Test should have the same quality standards as the rest of the code because you'll have to maintain them just the same. Our tests have to be portable like the rest of our code. Cheers Philippe |
On 24 October 2013 15:40, Philippe Marschall <[hidden email]> wrote:
Well, if you putting such high quality standards on Seaside, then logically i would expect more understanding from your side that people here also want to have quality standards for Pharo as well. And this issue with #shouldn't lies exactly in this plane. Because rephrasing you, running SLint on tests << doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain.>> :) Cheers -- Best regards, Igor Stasenko. |
In reply to this post by Philippe Marschall-2
On Thu, 24 Oct 2013, Philippe Marschall wrote:
> On 22.10.13 00:08, Camillo Bruni wrote: >> see my long explanation here >> https://pharo.fogbugz.com/default.asp?11876#87218 >> it looks unsuspicous until the moment you try understand such a failing >> assertion. > > This isn't moving Pharo foward. This doesn't make the system any more > flexible, adaptable, modular or malleable. This doesn't make the system any > easier to maintain. This doesn't make the system any smaller, faster, > scalable or secure. This doesn't make the system any easier to maintain. This > doesn't make life easier for anybody developing Pharo or using Pharo. This > doesn't improve Pharo in any way. > > This only adds code who's sole purpose is to break people's existing code. <rant> It's part of the Pharo manifesto: "Not backward compatible" </rant> Levente > > If you disagree with such a way of writing tests then the right solution IMHO > is to write a SLint rule. > > Cheers > Philippe > > > |
On 24 Oct 2013, at 18:32, Levente Uzonyi <[hidden email]> wrote: > On Thu, 24 Oct 2013, Philippe Marschall wrote: > >> On 22.10.13 00:08, Camillo Bruni wrote: >>> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 >>> it looks unsuspicous until the moment you try understand such a failing assertion. >> >> This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way. >> >> This only adds code who's sole purpose is to break people's existing code. > > <rant> > It's part of the Pharo manifesto: "Not backward compatible" > </rant> > And I still think that this was the best decision we ever took. It will allow us to have a future. Marcus |
In reply to this post by Levente Uzonyi-2
On 24 Oct 2013, at 18:32, Levente Uzonyi <[hidden email]> wrote: > On Thu, 24 Oct 2013, Philippe Marschall wrote: > >> On 22.10.13 00:08, Camillo Bruni wrote: >>> see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 >>> it looks unsuspicous until the moment you try understand such a failing assertion. >> >> This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way. >> >> This only adds code who's sole purpose is to break people's existing code. > > <rant> > It's part of the Pharo manifesto: "Not backward compatible" > </rant> <annoyed> Please go write those kind of comments on squeak-dev, nobody from Pharo ever does this on squeak-dev, ever. </annoyed> > > Levente > >> >> If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule. >> >> Cheers >> Philippe |
In reply to this post by Levente Uzonyi-2
> <rant>
> It's part of the Pharo manifesto: "Not backward compatible" > </rant> Levente I hope that writing this little pun created some jubilation to you. Or I do not understand your point. But this is ok for me. If pun on Pharo helps you then this is ok and they make me smile, and I'm serious If I can laugh from them this is that I should be quite strong no? We are all committed to build a robust and clean system that people can use to create their own wealth and feed their family. We are making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE. It is not easy but people like marcus, sven, esteban, igor, camillo and many many others are dedicated to that goal. All the rest does not matter :) I'm just sad that other smart people do not understand that we want to create a future to everybody not just a bunch of fun programmers else we would only focus on what is fun and exciting for us. Writing a new text editor is not what really makes igor having real fun but he does it because this is needed for y-our future. Same for esteban, removing Package info or improving our VM is not the most exciting topics but he does it and I thank them for that. Stef |
On Fri, 25 Oct 2013, Stéphane Ducasse wrote:
>> <rant> >> It's part of the Pharo manifesto: "Not backward compatible" >> </rant> > > Levente I hope that writing this little pun created some jubilation to you. Or I do not understand your point. > But this is ok for me. If pun on Pharo helps you then this is ok and they make me smile, and I'm serious > If I can laugh from them this is that I should be quite strong no? I'm sorry if you guys didn't get my message, but it was as serious as it could be. I understand that you don't what to be backwards compatible, because it makes it easier to change stuff. As I see, people need various levels of backwards compatibility. Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects. As time passes, and the number of users increases, you'll have to give in, and provide it some way. > > We are all committed to build a robust and clean system that people can use to > create their own wealth and feed their family. We are > making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE. I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste. I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view. Levente > It is not easy but people like marcus, sven, esteban, igor, camillo and many many others > are dedicated to that goal. > All the rest does not matter :) > > I'm just sad that other smart people do not understand that we want to create a future to everybody not just > a bunch of fun programmers else we would only focus on what is fun and exciting for us. Writing a new text editor is not what really makes igor having real fun but he does it because this is needed for y-our future. > Same for esteban, removing Package info or improving our VM is not the most exciting topics but he does it > and I thank them for that. > > Stef > > > |
> I'm sorry if you guys didn't get my message, but it was as serious as it could be. Ok fair :) > I understand that you don't what to be backwards compatible, because it makes it easier to change stuff. > As I see, people need various levels of backwards compatibility. Indeed but the right level is important ;) I help maintaining Moose and its several couple of tenth of packages as well as the pharoExtras packages so I think that I'm exposed to API changes. Just today I fixed the PharoSound package (full of ugly code BTW) > Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects. there is a bit of utopia there but why not. I prefer to see a system getting better than my code just loading in a system slowly improving. I can control when I want to migrate my apps. > As time passes, and the number of users increases, you'll have to give in, and provide it some way. What I was thinking for example (and I will build it) is an automatic stub creation to support the loading of package where a class is missing in the existing system. I also love the evolution analysis made by andre that generates rules to check migration we should add automatic code transformation. I would like to keep refactoring that we can apply when people want to migrate. And we will get there because we start to have a good infrastructure. So once the infrastructure does not suck all our time then we will build the next generation tools. And this is starting :) >> We are all committed to build a robust and clean system that people can use to >> create their own wealth and feed their family. We are >> making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE. > > I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste. You will complain about the fogbuz stuff and we will answer that we hate that google forced us to move. And this is like that. > I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view. It is just a question of view. For me a new compiler, debugger, inspector, filesystem, http server and many more is enough. And in addition the consortium means that slowly we will give an autonomous live to Pharo not based on free time of people. Stef |
On Fri, 25 Oct 2013, Stéphane Ducasse wrote:
> >> I'm sorry if you guys didn't get my message, but it was as serious as it could be. > > Ok fair :) > >> I understand that you don't what to be backwards compatible, because it makes it easier to change stuff. >> As I see, people need various levels of backwards compatibility. > > Indeed but the right level is important ;) > I help maintaining Moose and its several couple of tenth of packages as well as the pharoExtras packages > so I think that I'm exposed to API changes. Just today I fixed the PharoSound package (full of ugly code BTW) your own changes. > >> Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects. > > there is a bit of utopia there but why not. I prefer to see a system getting better than my code just loading in > a system slowly improving. I can control when I want to migrate my apps. This is where the level of backwards compatibility comes into the picture. For example the official release of Seaside is still based on Pharo 1.3, and the reason for that is the frequent changes of core functionality. > >> As time passes, and the number of users increases, you'll have to give in, and provide it some way. > > What I was thinking for example (and I will build it) is an automatic stub creation to support the > loading of package where a class is missing in the existing system. I don't see how this is benefical, or how it addresses the increasing demand for backwards compatibility. > I also love the evolution analysis made by andre that generates rules to check migration > we should add automatic code transformation. I would like to keep refactoring that we can apply > when people want to migrate. And we will get there because we start to have a good infrastructure. > So once the infrastructure does not suck all our time then we will build the next generation tools. > And this is starting :) > > >>> We are all committed to build a robust and clean system that people can use to >>> create their own wealth and feed their family. We are >>> making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE. >> >> I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste. > You will complain about the fogbuz stuff and we will answer that we hate that google forced us > to move. And this is like that. code changes. There are two kind of diffs posted to this mailing list. One for the changes on smalltalkhub, and the other is from github. The latter is totally useless, because it contains no code, just the name of the methods in the changed packages. The former is totally broken, because smalltalkhub can't create the diff, if the direct ancestor of the package is missing, and in 90%+ of the cases, you jump more than one mcz versions. > >> I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view. > > It is just a question of view. For me a new compiler, debugger, inspector, filesystem, http > server and many more is enough. And in addition the consortium means that slowly > we will give an autonomous live to Pharo not based on free time of people. I can only repeat myself; these changes are great, but it's not a breakthrough. Levente > > Stef > > > |
Free forum by Nabble | Edit this page |