Hi Dimitris, you have pointed out some good thoughts.
However, for me any technical thing can have two aspects: - solve a problem, provide a product which has value (for get things done) - take the concepts (of applied technics and computer science forward) For me, both things are important. Experience from doing gives new impulses for better concepts, better concepts may help to solve unsolvable problems. I like your example of libraries. Yes, I think too reinventing everything is not necessary. But I believe libraries as „live“ objects providing protocol and capabilities would be an important improvement. For me, Morphic in it’s essence could be great for the AR world to come. So in principle I agree with you, but I hope that we not stop to search also for better concepts in a world, where privacy and self will is called in the age of big data and AI. Just my personal view 😇 Cheers Hans > Am 06.11.2017 um 11:28 schrieb Dimitris Chloupis <kilon.al...@gmail.com>: > > all people like popular choices, including engineers. > > Engineers may be more careful but they are not known exactly for their talent > to innovate. > > We are pact animals, we are social animals. > > This is far from a coding problem, its pretty much coded right inside our > DNA, not just for us but also for any other animal. > > And we have our trends too, our resistance to git is an excellent example. A > general fixation of avoiding files and especially text files. The > unreasonable argument that you need an image to preserve a live coding > enviroment. The idea that just because you have access to the complete source > code , life becomes easier for some weird way as if people are likely to mess > with the internals of a system. That for some weird reason you cannot have > access to source code in other languages or that is hard to do so. The notion > that live coding is only possible or only easy in Smalltalk. That > reimplementing everything in Smalltalk is a great idea. That minimal syntax > equals softer learning curve. That Smalltalk is the only sensible way of > doing OOP. > > Finally but not least, "Alan Kay is god". > > People love to stick to their beliefs (me included) and not feel comfortable > questioning them. It's no surpise it tooks us hundrends of thousands of years > to get to this point. > > JS is chosen as a language for the same reason its so hated, its third party > libraries. As coders we have to rely a lot more to libraries than we have to > rely on languages. Sure a language can solve many potential problem but a > powerful library support can practically give you code on a plate. Hence also > why JS is practically non existant outside web dev and that is pretty rare > for a language. > > So sure popularity plays a major role but in the end the preference for JS is > not insanity, its the right choice for what it focuses on. A difficult/ not > that well designed language + big library support will always be easier to > use than a super ease elegant language without such big library support. The > time when we were relying on our code and our own libraries has passed long > time ago. > > > >> On Mon, Nov 6, 2017 at 10:37 AM Andrew Glynn <aglyn...@gmail.com> wrote: >> Btw, I think we gained pace when JS took over the front end, but lost >> visibility. Nothing is slower than coding a client/server app with the >> front end in JS. The ‘rise’ of JS is a side effect of the fact that the web >> was designed, built and continues to be built by ‘coders’ who don’t know >> enough to be called amateurs. >> >> >> >> What puts 'coders’ off though is related to way JS is and (mostly doesn’t) >> work. You can’t just sit down and ‘hack on’ Smalltalk until it ‘sorta >> kinda’ does what you want. You can’t grab code from some random website and >> ‘fiddle with it’ until it ‘sorta kinda’ works. ‘Coders’ can’t make it ‘sorta >> kinda’ work, and they don’t know how to write code that works. >> >> >> >> One of the better JS programmers I’ve worked with said at one point >> “Engineers can’t write JavaScript because it doesn’t fit their mentality. I >> used to be a retoucher, I’d spend hours and hours getting one pixel right. >> There’s no good reason that one pixel had to be that way, but the image >> didn’t ‘go’ otherwise. JavaScript is like that, you spend hours and hours >> messing with it, getting it to work, and at the end you don’t know why it >> works, nor why it didn’t. That’s not an engineer’s mindset.” >> >> >> >> Do aviation engineers choose tools based on ‘popularity’? At the same time, >> would you want your next flight to be on an aircraft running on JavaScript? >> I wouldn’t eat from a microwave running JavaScript. >> >> >> >> I’d rather be an engineer than a popularity contestant or a fashion victim. >> >> >> >> In any case, more often than not it’s management that chooses technologies, >> generally based on who they have lunch with more than anything else. >> >> >> >> Andrew >> >> >> >> Sent from Mail for Windows 10 >> >> >> >> From: Dimitris Chloupis >> Sent: Monday, November 6, 2017 2:35 AM >> >> >> To: Any question about pharo is welcome >> Subject: Re: [Pharo-users] Smalltalk Argument >> >> >> >> Another way of promoting Pharo is copying its advantages to other languages. >> The ideal way is for people to get straight to Pharo and fall in love with >> it. But sometimes this may be possible for several reasons. The most usual >> being that people simple are not in the mood of learning a new language >> unless they have to. As the saying goes "People love progress , its just >> that they equally hate change" >> >> >> >> Introducing similar features to another language, like I did with >> introducing live coding enviroment to Python with direct reference back to >> Pharo is a very good way to promote the language. Just because you cannot >> code in Pharo at your work does not mean you cannot code the Pharo way. Just >> put a huge tag in your documentation, comments and anywhere you mention your >> code "inspired by Pharo ( https://pharo.org)" and you will get their >> attention whether they like the idea of learning a new language or not. >> >> >> >> Its like watching an ad, using sex, humour and even unrelated stuff to grab >> your attention to a product. The idea here is to get the attention, once you >> do that, the rest follows. >> >> >> >> A huge problem with Smalltalk in general is that even though every language, >> enviroment, tool, IDE has been copying it , it is rarely mentioned. If it >> did , I have no doubt it would have been masively more popular than it is >> right now. >> >> >> >> On Mon, Nov 6, 2017 at 9:22 AM jtuc...@objektfabrik.de >> <jtuc...@objektfabrik.de> wrote: >> >> >> Phil, >> >> Am 26.10.17 um 08:17 schrieb p...@highoctane.be: >> > >> > >> > Now we miss the boat on mobile and bigdata, but this is solvable. >> >> You know, "It's solvable, and it's even easy in Smalltalk" has been what >> we've been shouting down at those worms in the C++/Java swamp for >> decades. We just never really proved it. We also missed the boat on web. >> Seaside was the last real innovation in that field, almost 15 years ago. >> When Javascript took over the frontend, we lost pace. >> >> > >> > If we had an open Java bridge (and some people in the community have >> > it for Pharo but do not open source it - so this is eminently doable) >> > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big >> > executable we would have a way to embed Pharo in a lot of places (e.g. >> > in the Hadoop ecosystem where fast starting VMs and small footprint >> > would make the cluster capacity x2 or x3 vs uberjars all over the >> > place) this would be a real disruption. >> >> To it sounds like a big ball of mud to me, but that is opinion ;-) >> >> > >> > Think about being able to call Pharo from JNA >> > https://github.com/java-native-access/jna the same way we use C with UFFI. >> > >> > Smalltalk argument for me is that it makes development bearable (even >> > fun and enjoyable would I say) vs the other stacks. That matters. >> > >> Yep. As long as there is no mobile, web or big data involved ;-) To me >> that is not enough for convincing project managers these days, because >> web, mobile and big data as well ass AI (oh, is that probably no. 4 on >> our list of missed boats?) are the topics of what we consider >> future-proof projects... I am not only dissing the Pharo community here, >> this is a problem for all Smalltalk vendors in my opinion. >> >> >> Joachim >> >> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> >>
