fair enough you think namespaces are not the right solution, what you think is the right solution then ?
As much I hate C++ , no I will have to disagree with your there, bad language design sure, but many of the "bad design" choices they make are based on the fact that this is a pure performance orientated language. Oh and we still wait for the real C++ alternative. Rust people claim they are close, D people claim they are close, everyone claims its very close, but still no alternative. Well I dont count C becaue its not OO, even if you claim C++ an abomination of OOP. I can guarantee that the dude that will come up with a language as fast as C++ and much better design he is going to make a fortune. In the mean time , those that have to use C++ will continue to use C++ and wait for the extemely remote competition to catch up. In the mean time C++ is the undisputed king in its speciality. Unfortunately coming up with a top performance language is a lot more than language design, live coding and OOP. Took ages for C and C++ to get to the level of optimisation they are nowdays. That's no easy feat even if you or I dont find interesting. So yes the modules that C++ will come up with, will be as ugly as hell, templates that suppose to be there as an alternative to dynamic typing etc are ugly as hell, but I dont see much protest in getting them removed. And there cases you cannot even use these "improvements" because ... well performance issues. While other languages worry how many times slower they are compared to C++, C++ worries about how much percentage of performance it loses with each added feature. C++ exits in a diffirent universe than the one that Smalltalk, Python, Ruby etc exist on and is a very lonely one. On Fri, Oct 13, 2017 at 10:55 AM Thierry Goubier <thierry.goub...@gmail.com> wrote: > Hi Kilon, > > disclaimer: I've used Parcplace Smalltlk without namespaces, then > VisualWorks with namespaces. > > 2017-10-13 9:08 GMT+02:00 Dimitris Chloupis <kilon.al...@gmail.com>: > >> Personally I dont get it, we find the path to bootstrap the pharo image >> clear and we cannot see the path to namespaces ? >> > > Because namespaces, by essence, come with serious issues. I won't take > someone seriously on namespaces until he can cite those faithfully. > > >> >> it makes zero sense to me >> >> Plus what you say, countless and countless of implementation of >> namespaces out there. And again what you say about perfection. >> >> If C++ can improve, If C++ can dream of namespaces planning the >> introduction of modules(in future version) in replacement (not removal) of >> his awful header file format.... I think we got the excuse to be confident >> we can come up with something decent. >> > > C++ is about adding incidental complexity to the development process, i.e. > how to make something complex where it could be done in a simpler way. > > So I'd be very wary of any innovation coming from that direction. > > >> >> We develop a freaking IDE for crying out loud. >> >> No it wont be a walk in the park, no it wont get done in one or next >> version, and no it cannot be an individual our outside effort. But we have >> the community super qualified to do it. >> > > And qualified enough maybe to also see it doesn't make that much of sense. > > Please remember that the design of a programming language consists not > just in a laundry list of features, but also in making judicious choices of > what to *omit* and, more importantly, in establishing design principles > that are easy to understand [Steele, 2003] > > Thierry > > >> On Fri, Oct 13, 2017 at 8:51 AM Ben Coman <b...@openinworld.com> wrote: >> >>> On Thu, Oct 12, 2017 at 8:52 PM, Sean P. DeNigris <s...@clipperadams.com >>> > wrote: >>> >>>> horrido wrote >>>> > Having separate namespaces would be really good. >>>> > VisualWorks has them. Why not Pharo? >>>> >>>> I can't remember ever hearing disagreement on this subject. It seems the >>>> only questions have been: 1) how to do them *right*, >>> >>> >>> The default position would be leveraging someone else's experience, so >>> this begs the question, what is wrong in namespace implementations in VW, >>> Gemstone, Squeak (as our immediate neighbours, then plus Dolphin, >>> SmalltalkX, other languages) >>> Are there been any research papers around comparing these? >>> >>> I found the "Pharo on Gemstone VM" talk impressive. The "develop on >>> Pharo deploy on Gemstone" philosophy seems like a nice synergy for Pharo's >>> commercial future. So a naive approach would be to do namespaces just like >>> Gemstone. Maybe its not the best, but would it be "good enough" -- >>> perfection being the enemy of done and all that jazz. >>> >>> cheers -ben >>> >>> >>>> and 2) where they fall on the endless prioritized todo list >>>> >>>
