Smalltalk Argument
Locked
 
|
Pharo can read Avro when this will be UFFI'ed But that is eminently doable. Phiil On Sun, Oct 29, 2017 at 7:13 PM, henry <[hidden email]> wrote:
|
|
|
In reply to this post by Offray Vladimir Luna Cárdenas-2
How could I get started documenting my components with Grafoscopio? I am interested in learning.
I just got ASN.1 lengths right, in Java. I am looking to Pharo and Java with an encrypted connection between them.
- HH
|
|
|
In reply to this post by philippeback
Interesting. Very.
Thank you.
- HH
|
Re: Smalltalk Argument
|
|
In reply to this post by henry
Read the User Manual [1] to install it and learn the basics of
its workings. Once you have created your first document or hit the
first bump, ask on this list. I will be around ;-). [1]
http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/manual.pdf Offray On 29/10/17 17:00, henry wrote:
How could I get started documenting my components with Grafoscopio? I am interested in learning. |
|
|
In reply to this post by dellani
Hi all,
an argument for Smalltalk, an discussion coming up many times in my history. It is also something I'm asking myself from time to time. It is very actual in the moment. Many good arguments were mentioned this discussion. I want to provide you my 2 cents on this. First, I'm taking the view of an hobby enthusiast. That's were I started. All the time I was excited by the Smalltalk concept. Live debugging, VM system, the possibility to look at and understand every code from systems completely new to me was so great. No installation, and nice people in the community. Conclusion: I want to do all in Smalltalk. Elegance is what rules only. Now, I'm in the perspective of an employed software developer. Everywhere that crazy C++, sometimes Fortran or C. Delphi. The people told "that's old, that was the beginning years ago, that is given, we have nothing else". And we have no time to redesign or port to something better, so fate catched us and we have to continue on the road to hell..... Most of my life colleagues were physicists who learned C++ for its thesis, or engineers of the embedded domain. No or only a few computer scientists. The rule now on these days: get ready, it should work somehow, costs. Elegance or sound design is no value. Not at this time. SW is just a part of my component as any screw and nail too. Continuing as a team leader. My goal is to fit budget. I have some time, and I have some people in the team. And I have to report and sell to my manager above me. I'm looking for get the job done, but I have also some strategic view. I've read some articles about this new .Net, with big potential, many libraries. Easy Web. Web is the future. I ask my team how to solve the task. Ony guy talks about Pearl. I hat Pearl. Another colleagues tells something about Smalltalk. Never heared of it, I ask if this is compatible to .Net.... My rules of success are in what I belief - and what can I sell to my big boss. And I belief only what I see... I could continue this. My point is: the Smalltalk Argument is depending on the perspective. And therefore, to communicate and argue about Smalltalk is what the receiver of the argument needs. Superiour technique can be an argument, but not always. Missing developer can be an argument, but not in every company and every project. My personal conclusion and look to Smalltalk is this: - for my soul which want to bring science and technology to the future, I look at the elegance and power of Smalltalk. That's why I'm looking at TeaTime and OpenCroquet again in the age of AR. - if I want to learn from top coders, the way of developing in Smalltalk (live debugging) - if I want to get a job done (for example a web site), I'm looking what the world offers me. And it may not be Smalltalk. In my current work, Game Engines matter. So coding a Game Engine in Smalltalk ? May be, but there are a lot of good products already... Having said that, the Smalltalk Argument has to sides, and they have both their value: - Smalltalk as an technique, as a matter of research and getting things better, an philosophy - Smalltalk as a product for people who want things get done. My personal opinion is that sometimes the point Smalltalk (or better now: Pharo) as a product is not so much in concern as it could. Pharo evolved wonderfully, the consortium and the organisation and the community have the right direction, yes. But as an industrial user of software I only can hope: keep the Smalltalk as a Product in the same focus as Smalltalk as the better technology. And product means: look at the needs the product is indented for, look at the "market". What are the problems out there ? If you can fit the needs, and provide a productive and integrable technology, you need no argument for Smalltalk. Off topic: thanks for the big effort of the community, it is really really fun today to work on and with Pharo. Much happend, and much is possible ;) Cheers Hans -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
|
In reply to this post by dellani
Hi all,
an argument for Smalltalk, an discussion coming up many times in my history. It is also something I'm asking myself from time to time. It is very actual in the moment. Many good arguments were mentioned this discussion. I want to provide you my 2 cents on this. First, I'm taking the view of an hobby enthusiast. That's were I started. All the time I was excited by the Smalltalk concept. Live debugging, VM system, the possibility to look at and understand every code from systems completely new to me was so great. No installation, and nice people in the community. Conclusion: I want to do all in Smalltalk. Elegance is what rules only. Now, I'm in the perspective of an employed software developer. Everywhere that crazy C++, sometimes Fortran or C. Delphi. The people told "that's old, that was the beginning years ago, that is given, we have nothing else". And we have no time to redesign or port to something better, so fate catched us and we have to continue on the road to hell..... Most of my life colleagues were physicists who learned C++ for its thesis, or engineers of the embedded domain. No or only a few computer scientists. The rule now on these days: get ready, it should work somehow, costs. Elegance or sound design is no value. Not at this time. SW is just a part of my component as any screw and nail too. Continuing as a team leader. My goal is to fit budget. I have some time, and I have some people in the team. And I have to report and sell to my manager above me. I'm looking for get the job done, but I have also some strategic view. I've read some articles about this new .Net, with big potential, many libraries. Easy Web. Web is the future. I ask my team how to solve the task. Ony guy talks about Pearl. I hat Pearl. Another colleagues tells something about Smalltalk. Never heared of it, I ask if this is compatible to .Net.... My rules of success are in what I belief - and what can I sell to my big boss. And I belief only what I see... I could continue this. My point is: the Smalltalk Argument is depending on the perspective. And therefore, to communicate and argue about Smalltalk is what the receiver of the argument needs. Superiour technique can be an argument, but not always. Missing developer can be an argument, but not in every company and every project. My personal conclusion and look to Smalltalk is this: - for my soul which want to bring science and technology to the future, I look at the elegance and power of Smalltalk. That's why I'm looking at TeaTime and OpenCroquet again in the age of AR. - if I want to learn from top coders, the way of developing in Smalltalk (live debugging) - if I want to get a job done (for example a web site), I'm looking what the world offers me. And it may not be Smalltalk. In my current work, Game Engines matter. So coding a Game Engine in Smalltalk ? May be, but there are a lot of good products already... Having said that, the Smalltalk Argument has to sides, and they have both their value: - Smalltalk as an technique, as a matter of research and getting things better, an philosophy - Smalltalk as a product for people who want things get done. My personal opinion is that sometimes the point Smalltalk (or better now: Pharo) as a product is not so much in concern as it could. Pharo evolved wonderfully, the consortium and the organisation and the community have the right direction, yes. But as an industrial user of software I only can hope: keep the Smalltalk as a Product in the same focus as Smalltalk as the better technology. And product means: look at the needs the product is indented for, look at the "market". What are the problems out there ? If you can fit the needs, and provide a productive and integrable technology, you need no argument for Smalltalk. Off topic: thanks for the big effort of the community, it is really really fun today to work on and with Pharo. Much happend, and much is possible ;) Cheers Hans -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
|
In reply to this post by Peter Fisk
Peter,
our mail provider decided to move all of the pharo mailing list messages to the spam folder, so I haven't seen many messages in the last days. I was already starting to wonder why nobody ever answered my posts ;-) Your smalltalk express idea sounds interesting. I look forward to trying it. Joachim Am 20.10.17 um 16:21 schrieb Peter Fisk:
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] 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 |
|
|
In reply to this post by philippeback
Phil, Am 26.10.17 um 08:17 schrieb [hidden email]: > > > 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:[hidden email] 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 |
|
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.
|
|
|
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: [hidden email] 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 [hidden email] <[hidden email]> wrote:
|
|
|
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 <[hidden email]> wrote:
|
|
|
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
|
|
|
In reply to this post by kilon.alios
Engineers don’t innovate often in core technologies, because they’re careful. Of course that also means they generally make terrible marketers 😊. They also don’t generally compete, which is part of the problem in this industry. The semiconductor industry, for instance, provides money to an independent institute, ISMI, that advances the core technologies they all use. We do love shiny new toys though, that’s half the reason we became engineers. You don’t ‘need’ an image by any means, but the fact that my live coding environments in Eclipse have been running, hiding behind modal dialogs, for 332, 468, and 992 hours respectively, due to constantly comparison between in-memory data and on-disk data combined with a crappy eventing model, implies that it’s at the very least much easier. Granted they’re building parts of a huge program, an ERP, and using JPA with it. Still, I have 3 Eclipse environments on 3 Sun servers with 64 threads each that have been untouchable for many days. Smalltalk is ‘a’ way, a way that doesn’t have the massive discrepancies between its syntactical appearance and dynamic implementation that C++ and Java suffer from, discrepancies that dynamically propagate depending on different libraries, frameworks, internal system states and external environments. Python is another way, it has plenty of strengths. Its weakness is that it doesn’t scale in terms of either data size or complexity. Odoo is a great case, most usable ERP out there for the end user, but if you try to run more than a few of the 40 odd modules it craps out. Largely that’s lack of time or investment, if you haven’t the latter, you need the former. IMO Python is closer to Smalltalk than GNU Smalltalk. But why compete? Where Python has strengths I use it, where there are reliable, stable technologies in Java I use them (Synapse and JINI are two main ones). If I have to do work in a browser I have to write JS, I just don’t try to do things it’s not reliably capable of. If I’m using ACT-R for modeling, I use LISP, for Wordnet I use Prolog. Writing any language in another, especially a language like C, is not going to work well in the long term, because while writing the language, one can’t be in that language’s proper mindset. As a result Ruby looks like Smalltalk but works like Java, except a Java without the massive investment that make actual Java somewhat reliable. Funny you mentioned Alan Kay, given I had a disagreement with him last night. His argument was that we need to think beyond Smalltalk, beyond anything out there at the moment. My argument was that we haven’t yet caught up to Smalltalk, never mind LISP, and that despite nearly everything we use having originated in those, most don’t even recognize it. We’re nowhere near ready for a new paradigm when we haven’t digested the old one yet. It was a polite disagreement. Nevertheless, AFAIK only God is God, and I don’t speak with him personally all that regularly 😉. Pharo is far from the Smallltalk I began with in ’88. Morphic is well beyond MVC and the improvements to it, combined with the things built on it, are keys to why I use Pharo. The JIT compiler is a another big improvement, which originated with Strongtalk - the PoC for the Java JIT compiler written by Sun. But when my first language, Forth, is still better than 90% of the ‘new’ languages out there, using those new languages as core technologies is problematic. New is better only if its actually better. Andrew Sent from Mail for Windows 10 From: [hidden email] 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 <[hidden email]> wrote:
|
|
|
In reply to this post by jtuchel
 https://youtu.be/S4E4tW0deIg Hello Joachim, This is my first post since 2017-10-20, so that may explain some of the missing replies ;). Smalltalk Express is syntax compatible with Pharo although much of the class structure is very different because of the foundation technologies. I will add a blog post soon to explain the differences. Above is an image and a short video showing a test of the desktop version with some animations. In the next few days, I hope to have another demo ready of Smalltalk running inside a Facebook page. Once that is working, I can use the Google server to connect client game apps using sockets. We all know that Smalltalk is a great language. If we can make it available where people spend their time (Facebook, Google), I am sure that it will become popular again. Maybe we can even connect Smalltalk applications through Twitter :) Here is my latest blog post. -- Peter On Mon, Nov 6, 2017 at 2:11 AM, [hidden email] <[hidden email]> wrote:
|
|
|
In reply to this post by Stephane Ducasse-3
> On Oct 28, 2017, at 2:05 AM, Stephane Ducasse <[hidden email]> wrote: > > Hi andrew > > you should contact esteban because he is writing an objective-C bridge. > > Stef Another one? I think we've written half a dozen now, no? There is some code in the VM libs that allows calling out. I worked on one with Avi for a bit about ten years ago. The callbacks/delegate bit was always problematic. It is one thing to call Objective C (really easy) but another thing to integrate with Cocoa and accept callbacks while keeping the VM live. I would really love one that let me write Cocoa from Pharo (especially iPhone apps). I do wonder if this new capability with Objective C blocks wouldn't maybe make things easier. http://www.friday.com/bbum/2011/03/17/ios-4-3-imp_implementationwithblock/ |
| Free forum by Nabble | Edit this page |