Re: [Pharo-project] Fwd: OverlyComplex
Igor Stasenko <siguctua@gmail.com>
Stef, is this an invitation to continue discussion? From ISSUE 1072: http://code.google.com/p/pharo/issues/detail?id=1072 ==============================================
The intent is that this issue, 1072, introduces some problems which motivate SLICE-remove-Complex. I intend to open two new issues to be paired with (unreleased) SLICE-basic-Complex and SLICE-extended-Complex. So I would prefer people to hold back discussions of other issues than removal of Complex code until I open those issues. Baby steps. OK? ============================================== So, this is an invitation to the discussion "Should the Complex class and associated code be removed from Pharo-Core?". This is NOT an invitation to a discussion of what is reasonable in an optional Complex package. ...
I don't want to be peevish here, but things like:
Note that there is no attempt to change oddities of Smalltalk syntax. E.g. Â (3 + 1/2i) --> Â (0 - 2i) Â NOT Â (3 + (1/2)i)
indicating that Ken don't realizing completely what is Smalltalk.
I indicated that I know the Smalltalk syntax by knowing that (3 + 1/2i) --> (0 - 2i) and indicating I would _not_ change that. Smalltalk syntax is certainly confusing to people which come from other languages which parse 1/2i as a number, which is why I pointed it out -- for people who don't know the Smalltalk parse strategy. I presume that you _do_ want users to switch to Smalltalk from other languages! Yes? -KenD
2009/8/19 <csrabak@bol.com.br>:
Em 18/08/2009 20:23, Ken.Dickey < Ken.Dickey@whidbey.com > escreveu:
Igor Stasenko <siguctua@gmail.com>
Stef, is this an invitation to continue discussion? From ISSUE 1072: http://code.google.com/p/pharo/issues/detail?id=1072 ==============================================
The intent is that this issue, 1072, introduces some problems which motivate SLICE-remove-Complex.
I intend to open two new issues to be paired with (unreleased) SLICE-basic-Complex and SLICE-extended-Complex.
So I would prefer people to hold back discussions of other issues than removal of Complex code until I open those issues.
Baby steps. OK? ==============================================
So, this is an invitation to the discussion "Should the Complex class and associated code be removed from Ph aro-Core?".
Yes.
This is NOT an invitation to a discussion of what is reasonable in an optional Complex package.
...
I don't want to be peevish here, but things like:
Note that there is no attempt to change oddities of Smalltalk syntax. E.g. Â (3 + 1/2i) -->Â (0 - 2i)Â NOTÂ (3 + (1/2)i)
indicating that Ken don't realizing completely what is Smalltalk.
Well, this comment was not really a inspired one, when I saw it I also had hitches to post a question to Igor to understand what was the complaint...
Because, to my sense, smalltalk having a few, brilliant concepts, and one of them is uniform syntax rules. If you start adding new rules - it is very likely that you'll make things overly complex & redundant. There are many studies showing that smalltalkers are times more productive than developers who using "industry" programming languages. Do you think they are all genious? Or maybe there is something which increasing their productivity?
I indicated that I know the Smalltalk syntax by knowing that (3 + 1/2i) --> (0 - 2i) and indicating I would _not_ change that.
Smalltalk syntax is certainly confusing to people which come from other languages which parse 1/2i as a number, which is why I pointed it out -- for people who don't know the Smalltalk parse strategy.
Also, Etoys already did somenthing about changing the syntax for mathematical operations http://www.squeakland.org/download/releaseNotes.jsp
I presume that you _do_ want users to switch to Smalltalk from other languages! Yes?
Ken,
Presently the driver for choosing a new platform is not only the language (here understood as the syntax of it).
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
El mié, 19-08-2009 a las 00:04 -0300, csrabak@bol.com.br escribió:
Em 18/08/2009 22:25, Igor Stasenko < siguctua@gmail.com > escreveu:
Em 18/08/2009 20:23, Ken.Dickey < Ken.Dickey@whidbey.com > escreveu:
[snipped]
I don't want to be peevish here, but things like:
Note that there is no attempt to change oddities of Smalltalk syntax. E.g. (3 + 1/2i) --> (0 - 2i) NOT (3 + (1/2)i)
indicating that Ken don't realizing completely what is Smalltalk.
Well, this comment was not really a inspired one, when I saw it I also had hitches to post a question to Igor to understand what was the complaint...
Because, to my sense, smalltalk having a few, brilliant concepts, and one of them is uniform syntax rules.
I agree 99.9%.
If you start adding new rules - it is very likely that you'll make things overly complex & redundant.
Is a risk all languages that evolve and attempt to be all encompassing run into, and again I'm with you on attemting to avoid this deadly downward spiral.
There are many studies showing that smalltalkers are times more productive than developers who using "industry" programming languages. Do you think they are all genious?
I don't want to rain in your party, but I work with benchmarking of application development for more than ten years and I have to inform you that this statement does not stand.
Perhaps when Smalltalk was near its inception and other platforms were in their infancy this kind of rept could be called by smalltalkers when buiding complex GUI apps, but right now there is no headway for Smalltalk...
Maybe you can tell us how much time would you estimate for a java (or better yet, c++) version of Seaside or maybe of GLORP, that were made for a significant part of their initial life for a single person. I *am* times more productive in Smalltalk than in Java or PHP or C, even if I can not show an *enterprise* benchmark the kind of ones that Garner and friends so happily like to show in magazines and flyers. So, a lot of people here can attest that indeed it is more productive to work in Smalltalk taht in other languages, and that is the reason why this *myth* persist. Maybe subjective, maybe not. We know that when we work in Smalltalk and think how much more time/work/effort/boredom will take to do the same on other languages.
Today, due the minute participation of Smalltalk in world production of new funcionality, you cannot find in any commercial or publicly available database on productivity (like ISBSG http://www.isbsg.org/) it mentioned by itself, but only lumped as OTHER 4GL).
For a more or less uptodate and public reference, give a look at http://www.qsm.com/?q=resources/function-point-languages-table/index.html
WTF. From the page: What is a gearing factor? The gearing factor is simply the average number of Source Lines of Code (SLOC) per function point in the completed project. It is calculated by dividing the final code count for a completed project by the final function point count. SLOC counts are logical, not physical line counts. Nuts, is this how the *enterprise* projects are evaluated? That is absolute non-sense. What is the difference between logical and physical line counts?
Or maybe there is something which increasing their productivity?
As you make the rept "are they all genious", I counter with: would you accept/believe that all managers who're responsible for development worldwide are "pointed haired bosses" which cannot discover if such a thing as 'silver bullet' existed?
Most productivity is obtained due discipline, processes, trained and motivated people, and one of the last factors is programming language syntax. Programming language technology obviously has a role, otherwise it would be indifferent programming in (say) Smalltalk, versus (say) assembly.
More non-sense, the process isn't a factor. The very same person can do sometimes the same work in a week or in a night with coffee. WE ARE NOT machines producing nails in a predictable, constant over time, unaffected by personal affairs. This factory model doesn't work and has never worked. And the ever increasing complexity and irreal methods created to try to measure people are a sad result of this way of thinking. I believe that the work we do is more akin to the artistic disciplines. Will you try to measure the work done by a musician? or a painter? That is why the pointed haired bosses depiction and Dilbert cartoons are so popular.
HTH
--
Cesar Rabak
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
El mié, 19-08-2009 a las 00:04 -0300, csrabak@bol.com.br escribió: Miguel,
Em 18/08/2009 22:25, Igor Stasenko < siguctua@gmail.com > escreveu:
Em 18/08/2009 20:23, Ken.Dickey < Ken.Dickey@whidbey.com > escreveu:
[snipped] [snipped]
Maybe you can tell us how much time would you estimate for a java (or better yet, c++) version of Seaside or maybe of GLORP, that were made for a significant part of their initial life for a single person.
This kind of repts have been used for year to attempt to prove a lot of non provable things: a similar argument was used to attempt to "demonstrate" that Linus Torvalds could have written the kernel for Linux [which applies for the requirement of yours "...significant part of their initial life for a single person."] Other languages/technologies all have histories, but see: this in logic is considered the fallacy of cherry picking, where an interesting and sufficiently high profile case can be shown off (a famous one is the developmet of the Viaweb site [http://en.wikipedia.org/wiki/Viaweb]). The issue about productivity and discussions about differences thereof due languages is the _average_ productivity for the mass of active users.
I *am* times more productive in Smalltalk than in Java or PHP or C, even if I can not show an *enterprise* benchmark the kind of ones that Garner and friends so happily like to show in magazines and flyers.
I don't deny you can be, as I am. I can tell why it is in my case. If you and we cannot show hard data on an *enterprise* benchmark (I represent in this country one of the friends and used to work to the mentioned) you'll a *lot* of difficulty on convincing companies to embrace this technology.
So, a lot of people here can attest that indeed it is more productive to work in Smalltalk taht in other languages, and that is the reason why this *myth* persist. Maybe subjective, maybe not. We know that when we work in Smalltalk and think how much more time/work/effort/boredom will take to do the same on other languages.
My contribution to this debate is that if we don't bring demonstrable data to become facts, we will continue to be heard as some kind of hacker of a wacky or semi-defunct language (depending upon the thoughts of the listener).
Today, due the minute participation of Smalltalk in world production of new funcionality, you cannot find in any commercial or publicly available database on productivity (like ISBSG http://www.isbsg.org/) it mentioned by itself, but only lumped as OTHER 4GL).
For a more or less uptodate and public reference, give a look at http://www.qsm.com/?q=resources/function-point-languages-table/index.html
WTF. From the page:
What is a gearing factor? The gearing factor is simply the average number of Source Lines of Code (SLOC) per function point in the completed project. It is calculated by dividing the final code count for a completed project by the final function point count. SLOC counts are logical, not physical line counts.
Nuts, is this how the *enterprise* projects are evaluated? That is absolute non-sense. What is the difference between logical and physical line counts?
The main point of the text you read is that the evaluations should be done asap in IFPUG Funtion Points or similar metric. The proviso thy put there is to allow different coding practices to be accomodated without inflating the outcomes. A lot of languages allow more than a logical statement to put in a single line, or for aesthetical reasons break a single statement in more than a single line.
Or maybe there is something which increasing their productivity?
As you make the rept "are they all genious", I counter with: would you accept/believe that all managers who're responsible for development worldwide are "pointed haired bosses" which cannot discover if such a thing as 'silver bullet' existed?
Most productivity is obtained due discipline, processes, trained and motivated people, and one of the last factors is programming language syntax. Programming language technology obviously has a role, otherwise it would be indifferent programming in (say) Smalltalk, versus (say) assembly.
More non-sense, the process isn't a factor. The very same person can do sometimes the same work in a week or in a night with coffee.
A single *task* yes! A complete project like the Pharo revamp of a renewed Squeak *not*! That's where processes come into play and modify the outcomes.
WE ARE NOT machines producing nails in a predictable, constant over time, unaffected by personal affairs. This factory model doesn't work and has never worked. And the ever increasing complexity and irreal methods created to try to measure people are a sad result of this way of thinking.
Agreed. It is not for this that development processes are for. It would become out topic here so I refrain of further discussion.
I believe that the work we do is more akin to the artistic disciplines.
This kind of thinking is an attempt to evade the necessary debate. Most of software development is not of pure conception but turning into some usable artifact the conception. I would quote T.A.Edison on his saying about "1% inspiration and 99% transpiration.", processes is to make us more productive in 99% part of the job!
Will you try to measure the work done by a musician? or a painter?
When [s]he is composing, probably not (but: get a look at the Movie and Advertising industries), when they're playing or the painter is applying the picture in church's roof, *yes*.
That is why the pointed haired bosses depiction and Dilbert cartoons are so popular.
I agree they are popular, but remember that geeks and nerd depictions are also popular! Regards, -- Cesar Rabak
On Wed, Aug 19, 2009 at 9:55 AM, <csrabak@bol.com.br> wrote:
El mié, 19-08-2009 a las 00:04 -0300, csrabak@bol.com.br escribió: Miguel,
Em 18/08/2009 22:25, Igor Stasenko < siguctua@gmail.com > escreveu:
Em 18/08/2009 20:23, Ken.Dickey < Ken.Dickey@whidbey.com > escreveu:
[snipped] [snipped]
Maybe you can tell us how much time would you estimate for a java (or better yet, c++) version of Seaside or maybe of GLORP, that were made for a significant part of their initial life for a single person.
This kind of repts have been used for year to attempt to prove a lot of non provable things: a similar argument was used to attempt to "demonstrate" that Linus Torvalds could have written the kernel for Linux [which applies for the requirement of yours "...significant part of their initial life for a single person."]
Other languages/technologies all have histories, but see: this in logic is considered the fallacy of cherry picking, where an interesting and sufficiently high profile case can be shown off (a famous one is the developmet of the Viaweb site [http://en.wikipedia.org/wiki/Viaweb]).
Well maybe you are right, maybe not. More examples that were never *managed* in an enterprise way: Non-commercial: Ruby On Rails Tomcat Apache web server FreeBSD/NetBSD/OpenBSD Squeak Pharo Commercial: Amazon Facebook Google 37signals.com Failed ones, well a lot more than can be described, although they are almost never publicly mentioned. Lots of project from Consulting houses using *enterprise* products as ERP and processes like RUP (and others even more "proved"), with ISO certifications on processes have failed espectacularly. Here in my work, at least 3 projects done by external consulting firms have failed and took a lot more time and resources than the initially estimated. Also the poor souls that they bring to work in the project keep changing every 2 or 3 month (burned by the pressure and the impossible deadlines), and we have had 3 managers for one of these projects. So, yes, I have a very bad impression. Maybe it is just bad luck. Who knows? My friends on other places tell similar stories. So, as you say, nothing can be take for granted on a project both *managed* and *unmanaged* projects can fail, but the fact that a lot of unmanaged projects succeed, makes me wonder of the usefulness of the enterprise *ways* of work. But, lets no start a flame here. I respect your opinion about *managed* projects and have my opinion about *unmanaged* projects. The enterprise world will never change.
The issue about productivity and discussions about differences thereof due languages is the _average_ productivity for the mass of active users.
I *am* times more productive in Smalltalk than in Java or PHP or C, even if I can not show an *enterprise* benchmark the kind of ones that Garner and friends so happily like to show in magazines and flyers.
I don't deny you can be, as I am. Â I can tell why it is in my case.
If you and we cannot show hard data on an *enterprise* benchmark (I represent in this country one of the friends and used to work to the mentioned) you'll a *lot* of difficulty on convincing companies to embrace this technology.
I am 100% agree with you, sadly that it what the "pointed haired bosses" want to save its asses in the case a project fails. That way they at least can say that it was not because of a bad technology election. How the say goes? Nobody has been fired for choosing IBM? Now you have ISO900*, RUSP, SAP, oracle, etc. :)
So, a lot of people here can attest that indeed it is more productive to work in Smalltalk taht in other languages, and that is the reason why this *myth* persist. Maybe subjective, maybe not. We know that when we work in Smalltalk and think how much more time/work/effort/boredom will take to do the same on other languages.
My contribution to this debate is that if we don't bring demonstrable data to become facts, we will continue to be heard as some kind of hacker of a wacky or semi-defunct language (depending upon the thoughts of the listener).
But hey, that is not a goal of the smalltalk community, to appeal and to be the first option for a new project as the java guys, for example, want. We know that there are right tools for each problem in hand. The Pharo project has a goal of be a platform for enterprise apps, but that is different to want to be *the* platform for enterprise apps. Take the case of ruby on rails (and dynamic languages too), 5 years ago it was crazy to even propose them on a meeting for a new project. Now even SUN is sponsoring them on their vm. Times changes, and with time (and even more with the apropriate marketing) the technologies will reach the key people on enterprises and will be an option, even if no metric can be shown for them.
Today, due the minute participation of Smalltalk in world production of new funcionality, you cannot find in any commercial or publicly available database on productivity (like ISBSG http://www.isbsg.org/) it mentioned by itself, but only lumped as OTHER 4GL).
For a more or less uptodate and public reference, give a look at http://www.qsm.com/?q=resources/function-point-languages-table/index.html
WTF. From the page:
What is a gearing factor? The gearing factor is simply the average number of Source Lines of Code (SLOC) per function point in the completed project. It is calculated by dividing the final code count for a completed project by the final function point count. SLOC counts are logical, not physical line counts.
Nuts, is this how the *enterprise* projects are evaluated? That is absolute non-sense. What is the difference between logical and physical line counts?
The main point of the text you read is that the evaluations should be done asap in IFPUG Funtion Points or similar metric. The proviso thy put there is to allow different coding practices to be accomodated without inflating the outcomes. A lot of languages allow more than a logical statement to put in a single line, or for aesthetical reasons break a single statement in more than a single line.
Yes, I know that, but my point is: What that does show about a project? A closure in Smalltalk it is more powerfull and usefull that 100 lines of java code or 1000 lines of java code. But a the very same code could be produced in java by using the apropriate library and reduce the line count from 100 to 1. What does that demonstrate? That java is on par with smalltalk? That java it is not just 10 times more productive than c++ but but 1000 times better. I am exaggerating, I know that the numbers are not used that way, but you get my point: although the metrics are promoted as more enterprisey, they aren't. In a certain leve, they are arbitrary.
Or maybe there is something which increasing their productivity?
As you make the rept "are they all genious", I counter with: would you accept/believe that all managers who're responsible for development worldwide are "pointed haired bosses" which cannot discover if such a thing as 'silver bullet' existed?
Most productivity is obtained due discipline, processes, trained and motivated people, and one of the last factors is programming language syntax. Programming language technology obviously has a role, otherwise it would be indifferent programming in (say) Smalltalk, versus (say) assembly.
More non-sense, the process isn't a factor. The very same person can do sometimes the same work in a week or in a night with coffee.
A single *task* yes! A complete project like the Pharo revamp of a renewed Squeak *not*!
That's where processes come into play and modify the outcomes.
WE ARE NOT machines producing nails in a predictable, constant over time, unaffected by personal affairs. This factory model doesn't work and has never worked. And the ever increasing complexity and irreal methods created to try to measure people are a sad result of this way of thinking.
Agreed. It is not for this that development processes are for. It would become out topic here so I refrain of further discussion.
I believe that the work we do is more akin to the artistic disciplines.
This kind of thinking is an attempt to evade the necessary debate. Â Most of software development is not of pure conception but turning into some usable artifact the conception. I would quote T.A.Edison on his saying about "1% inspiration and 99% transpiration.", processes is to make us more productive in 99% part of the job!
Will you try to measure the work done by a musician? or a painter?
When [s]he is composing, probably not (but: get a look at the Movie and Advertising industries), when they're playing or the painter is applying the picture in church's roof, *yes*.
That is why the pointed haired bosses depiction and Dilbert cartoons are so popular.
I agree they are popular, but remember that geeks and nerd depictions are also popular!
Regards,
-- Cesar Rabak
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/19 Ken.Dickey <Ken.Dickey@whidbey.com>:
Igor Stasenko <siguctua@gmail.com>
Stef, is this an invitation to continue discussion? From ISSUE 1072: Â Â http://code.google.com/p/pharo/issues/detail?id=1072 ==============================================
The intent is that this issue, 1072, introduces some problems which motivate SLICE-remove-Complex.
I intend to open two new issues to be paired with (unreleased) SLICE-basic-Complex and SLICE-extended-Complex.
So I would prefer people to hold back discussions of other issues than removal of Complex code until I open those issues.
Baby steps. OK? ==============================================
So, this is an invitation to the discussion "Should the Complex class and associated code be removed from Pharo-Core?".
This is NOT an invitation to a discussion of what is reasonable in an optional Complex package.
...
I don't want to be peevish here, but things like:
Note that there is no attempt to change oddities of Smalltalk syntax. E.g. Â (3 + 1/2i) --> Â (0 - 2i) Â NOT Â (3 + (1/2)i)
indicating that Ken don't realizing completely what is Smalltalk.
I indicated that I know the Smalltalk syntax by knowing that  (3 + 1/2i) -->  (0 - 2i) and indicating I would _not_ change that.
Smalltalk syntax is certainly confusing to people which come from other languages which parse 1/2i as a number, which is why I pointed it out -- for people who don't know the Smalltalk parse strategy.
I presume that you _do_ want users to switch to Smalltalk from other languages! Â Yes?
sure i want. I had discovered smalltalk maybe 4 years ago. Before that i knew nothing about smalltalk but already had a programming experience more than a 15 years. But i never, never had a thought to call smalltalk syntax odd. It is most simple & consistent computer language syntax ever designed. I having much more reasons to call a math precedence rules odd, because they are many and you need to learn them and you spending a countless hours in school to learn them. If you remember your childhood - how many pupils (including you) , who had to study math found the math precedence rules odd, confusing and hard to grok them? Compare Roman numeric system with Arabic. Why do you think, a middle-age Europeans and then whole world started using Arabic numeric system instead of Roman? The problem here is with a pattern which sits deep in your brains and preventing you to understand a much more simpler and easy to master concept(s).
-KenD
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (5)
-
csrabak＠bol.com.br -
Igor Stasenko -
Ken.Dickey -
Miguel Cobá -
Miguel Enrique Cobá Martinez