2017-10-13 10:12 GMT+02:00 Dimitris Chloupis <kilon.al...@gmail.com>:
> fair enough you think namespaces are not the right solution, what you > think is the right solution then ? > I told you. Namespaces are a solution, but they come with issues. > > 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. > No. In the HPC world, a common held position is that Fortran code is 30% faster than C++. Remember that part of my job is to write compilers. I'm also consider a guy to talk to when someone has deep issues with some of the new features of C++... even if I don't do C++, I can often reframe what the feature means in the overall scheme of programming languages. > > 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. > I find it very interesting. I consider that current compilers are very good optimising code that is written in a language that obscures the developper intent in the first place. > > 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. > As I told you, I work in a world where performance is paramount and C++ is strongly criticized for the fact its incidental complexity makes it very very hard to reach or maintain performance levels (compared to Fortran, say). Thierry > > 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 >>>>> >>>>
