[Pharo-project] JSON, Smalltalk parser and no-point wars
Friends, what energy! But I don't know why are we discussing this point of JSON choice so long. It is an implementation detail. If he choose to use XML, so be. It is Dale's time and Dale's code. Remember his projects is not to build a inter-dialect metadata format. His project is all about building an inter-dialect package format to store smalltalk. And in that goal he is succeeding! Lets no make a flame war about his choices. What is matters now is to show to as many smalltalk dialects as possible, that code interchange is possible. That is the fucking point. If after that, because the implementation is slow, or some other real after-use problem is detected, then is the time to discuss how to better address that specific problem. Until then, this is a bikeshedding like inane problem. Remember make it work, make it right, make it fast! Dale is in make it work. Every other not putting code on the project is trying to make it right (intelectually and upfront). Lets not stop the work of others by discussing the best way to do it instead of doing it. Some famous people around here made an analogy about a mountain and the people trying to climb it. Don't forget that! Cheer to all. -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
On Apr 24, 2012, at 5:34 PM, Miguel Cobá wrote:
Friends,
what energy! But I don't know why are we discussing this point of JSON choice so long. It is an implementation detail. If he choose to use XML, so be. It is Dale's time and Dale's code. Remember his projects is not to build a inter-dialect metadata format. His project is all about building an inter-dialect package format to store smalltalk. And in that goal he is succeeding! Lets no make a flame war about his choices. What is matters now is to show to as many smalltalk dialects as possible, that code interchange is possible. That is the fucking point.
No! Because really fast we will have a lot of Smalltalk code on github and we will have to have JSON parser to build tools. While we can simply use our parser. So I'm writing a parser not for us but for gemstone basically right now.
If after that, because the implementation is slow, or some other real after-use problem is detected, then is the time to discuss how to better address that specific problem. Until then, this is a bikeshedding like inane problem.
Remember make it work, make it right, make it fast!
Yes but in that case using the gemstone parser should have worked too. I thought that making it secure was after make it work.
Dale is in make it work. Every other not putting code on the project is trying to make it right (intelectually and upfront).
Lets not stop the work of others by discussing the best way to do it instead of doing it. Some famous people around here made an analogy about a mountain and the people trying to climb it. Don't forget that!
Do you think that we forget when we are daily improving our system?
Cheer to all. -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
Stef, The smalltalk tools have no more business poking around in the "internals" of the disk-based package format than they do unzipping and rummaging around inside a .mcz file. Once the package is in the image you are working with Cypress or FileTree definitions that look an awful lot like Monticello definitions ... you'll be hard-pressed to find any json in those classes ... you will find some Dictionaries ... and those are the classes that the smalltalk tools should be using ... As I have said (something like a 100 times so far) the Cypress format will be changing over time so it will be a major mistake for any image-based tools to be monkeying with the internals of the disk-based package format ... Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 3:03:05 PM | Subject: Re: [Pharo-project] JSON, Smalltalk parser and no-point wars | | | On Apr 24, 2012, at 5:34 PM, Miguel Cobá wrote: | | > Friends, | > | > what energy! But I don't know why are we discussing this point of | > JSON | > choice so long. | > It is an implementation detail. | > If he choose to use XML, so be. It is Dale's time and Dale's code. | > Remember his projects is not to build a inter-dialect metadata | > format. | > His project is all about building an inter-dialect package format | > to | > store smalltalk. And in that goal he is succeeding! Lets no make a | > flame | > war about his choices. | > What is matters now is to show to as many smalltalk dialects as | > possible, that code interchange is possible. That is the fucking | > point. | | No! | Because really fast we will have a lot of Smalltalk code on github | and we will have | to have JSON parser to build tools. While we can simply use our | parser. So I'm writing a parser | not for us but for gemstone basically right now. | | > If after that, because the implementation is slow, or some other | > real | > after-use problem is detected, then is the time to discuss how to | > better | > address that specific problem. Until then, this is a bikeshedding | > like | > inane problem. | > | > Remember make it work, make it right, make it fast! | | Yes but in that case using the gemstone parser should have worked | too. | I thought that making it secure was after make it work. | | | > Dale is in make it work. | > Every other not putting code on the project is trying to make it | > right | > (intelectually and upfront). | > | > Lets not stop the work of others by discussing the best way to do | > it | > instead of doing it. Some famous people around here made an analogy | > about a mountain and the people trying to climb it. Don't forget | > that! | | Do you think that we forget when we are daily improving our system? | | | > | > Cheer to all. | > -- | > Miguel Cobá | > http://twitter.com/MiguelCobaMtz | > http://miguel.leugim.com.mx | > | > | > | > | | |
bikeshed.... let's wait and see how the first implementation will run and behave in a working system honestly there are more pressing issues than the format of some meta-data... On 2012-04-25, at 00:22, Dale Henrichs wrote:
Stef,
The smalltalk tools have no more business poking around in the "internals" of the disk-based package format than they do unzipping and rummaging around inside a .mcz file. Once the package is in the image you are working with Cypress or FileTree definitions that look an awful lot like Monticello definitions ... you'll be hard-pressed to find any json in those classes ... you will find some Dictionaries ... and those are the classes that the smalltalk tools should be using ...
As I have said (something like a 100 times so far) the Cypress format will be changing over time so it will be a major mistake for any image-based tools to be monkeying with the internals of the disk-based package format ...
Dale
----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Tuesday, April 24, 2012 3:03:05 PM | Subject: Re: [Pharo-project] JSON, Smalltalk parser and no-point wars | | | On Apr 24, 2012, at 5:34 PM, Miguel Cobá wrote: | | > Friends, | > | > what energy! But I don't know why are we discussing this point of | > JSON | > choice so long. | > It is an implementation detail. | > If he choose to use XML, so be. It is Dale's time and Dale's code. | > Remember his projects is not to build a inter-dialect metadata | > format. | > His project is all about building an inter-dialect package format | > to | > store smalltalk. And in that goal he is succeeding! Lets no make a | > flame | > war about his choices. | > What is matters now is to show to as many smalltalk dialects as | > possible, that code interchange is possible. That is the fucking | > point. | | No! | Because really fast we will have a lot of Smalltalk code on github | and we will have | to have JSON parser to build tools. While we can simply use our | parser. So I'm writing a parser | not for us but for gemstone basically right now. | | > If after that, because the implementation is slow, or some other | > real | > after-use problem is detected, then is the time to discuss how to | > better | > address that specific problem. Until then, this is a bikeshedding | > like | > inane problem. | > | > Remember make it work, make it right, make it fast! | | Yes but in that case using the gemstone parser should have worked | too. | I thought that making it secure was after make it work. | | | > Dale is in make it work. | > Every other not putting code on the project is trying to make it | > right | > (intelectually and upfront). | > | > Lets not stop the work of others by discussing the best way to do | > it | > instead of doing it. Some famous people around here made an analogy | > about a mountain and the people trying to climb it. Don't forget | > that! | | Do you think that we forget when we are daily improving our system? | | | > | > Cheer to all. | > -- | > Miguel Cobá | > http://twitter.com/MiguelCobaMtz | > http://miguel.leugim.com.mx | > | > | > | > | | |
Dne 25. 04. 2012 00:03, piše Stéphane Ducasse:
Because really fast we will have a lot of Smalltalk code on github and we will have to have JSON parser to build tools. While we can simply use our parser. So I'm writing a parser not for us but for gemstone basically right now.
Be sure that your parser will be available on all Smalltalks, not just Pharo. And upfront. Including Amber. Without that no chance for broader adoption. This was a problem of most such trials so far. Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Because really fast we will have a lot of Smalltalk code on github and we will have to have JSON parser to build tools. While we can simply use our parser. So I'm writing a parser not for us but for gemstone basically right now.
Be sure that your parser will be available on all Smalltalks, not just Pharo. And upfront. Including Amber.
Without that no chance for broader adoption. This was a problem of most such trials so far.
This is the idea. Else for pharo we already have it. Stef
Best regards Janko
-- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
Miguel Cobá wrote
Friends,
what energy!
Right on!! I like these passionate exchanges. It reminds me how different our community is from a "job". We care deeply about beauty, truth and goodness; and our work is an expression of that. Now let's harness this energy to accelerate the already-amazing pace of our progress! Your friend, Sean -- View this message in context: http://forum.world.st/JSON-Smalltalk-parser-and-no-point-wars-tp4583877p4589... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (6)
-
Camillo Bruni -
Dale Henrichs -
Janko Mivšek -
Miguel Cobá -
Sean P. DeNigris -
Stéphane Ducasse