8 ms·

How to Evangelize a Programming Language

37 points by louiscyphre 7y ago

deleted 7y ago
[deleted]
tabtab 7y ago
This article has only one real tip: create a high school programming contest for it. The rest is evangelizing a specific language itself, which I won't mention to avoid fueling the gimmick. I think we've been had. In general programming language preferences are subjective. We all think different. I've been in many many debates over language merit. The only language that would truly make one happy is one custom fit for his/her own head. I personally want something that leverages the database more so I don't have to do data chomping in code, nor reinvent the schema in code (DRY). I'd also like custom block-scoping so that one is not stuck choosing between OOP or FP etc. A code-block's scope would be programmer-defined. You could roll our own control and class-like constructs. Actually some languages are meta (bend-able) enough to reshape almost any way you want, but then in a team environment, you have to face others' custom mind-fit code, which defeats the purpose.
- codr7 7y ago
  One way that I feel comfortable with is publishing clear, real life-ish examples of what can be accomplished in the language by playing on it's strengths. Debating merits never really leads anywhere, all languages have strengths and weaknesses, all languages are compromises in some respect. I've put quite some effort into the DRY database schema problem over the years. The only reasonable way forward that I've found is defining the schema in code and creating the database from that definition. SQL is a definitely more primitive and limited than most programming languages, so it makes perfect sense to generate it. And the only way to truly custom fit a language is to create it [0]. [0] https://github.com/codr7/gfoo https://github.com/codr7/gfoo
  - tabtab 7y ago
    Rather than rely on SQL, why not put the common info in tables? A "data dictionary" (DD). If tools can extract or sync that up to the actual schema, that's a great bonus, but is not a prerequisite. Using things POC annotations is ugly and hard to track. And we don't have to rely on the DD to do everything. Of course intricate business logic should be in app code, but app code shouldn't reinvent the obvious things like minimum length ("required"), max length, field description, synopsis (longer "help"), display order, key type (primary, foreign) and their related "look-up" references, etc. I've found that if the DD results can be intercepted by the program, then it's more flexible. It should have an event that allows the DD attributes to be programmatically altered per screen, and then another event to modify or remove the actual HTML and/or SQL generated from the those attributes. I call it "staged rendering". This allows the DD to do 90% of the grunt work, but not limit local customization. Local customization has been the most common bottleneck of past DD-based attempts. I like it when computers do the grunt work; that's what they were invented for. Our current common CRUD stacks violate data-related D.R.Y. up the wazoo and nobody seems to care as long as they get a paycheck. Auto code generation is only a half solution because once you alter the copies, you can't rely on generators anymore: they wipe out your custom code.
    - codr7 7y ago
      Interesting. I never use annotations in my own tools, I add first class abstractions for whatever database features I need and free form records to shuffle data. So there will be something called a Table, with Columns and Keys. It's not so much reinventing as bridging, an FFI doesn't reinvent the library it imports. And yes, that means you can't modify the database from the bottom any more. But you're not losing any power, since any random programming language is more flexible and convenient. Most databases come with some kind of built-in DD, I've used them in Firebird & Postgres to read primary- and foreign keys while I was still investigating the approach. But it never really clicks for me, because the database is not the software, it's where the software stores its data. Tying application logic and presentation to the relational structure of the data just doesn't make any sense to me.
- kthielen 7y ago
  I think that part of the problem is to define data structures in a way that can be produced and consumed in multiple languages, algebraic data types are a good "least common denominator" for this. Also w.r.t. reinventing the schema for databases, I have got a lot of mileage out of deriving the schema from code. Shameless plug, I have this little project (https://github.com/Morgan-Stanley/hobbes/ https://github.com/Morgan-Stanley/hobbes/) where we have a self-contained header-only library to push structured data out of process with minimal latency, query data concurrently with a Haskell-like PL. It works well for our kinds of systems (millions of orders per day, ~1 billion market data ticks, structured log data from multiple systems involved, ...).
  - tabtab 7y ago
    Attributes are usually easier to share than functions and algorithms. That's why I suggest using "data dictionaries" nearby. Most common CRUD idioms are readily attribute-able such that we don't need Turing Complete sub-languages for majority of them. We just need useful code "hooks" to customize when needed, which is the usual bottleneck of attribute-driven development.
- louiscyphre 7y ago
  > This article has only one real tip: create a high school programming contest for it. Yes, but this "tip" was demonstrated by an example. The example is a Pharo-based programming competition, so it's reasonable to say a few words about Pharo. Otherwise, the article would be pretty darn brief!
  - zapzupnz 7y ago
    > Otherwise, the article would be pretty darn brief! It is pretty darn brief. The title and first few paragraphs would lead one to believe that the article is going to be about programming language evangelisation. Instead, it's nothing of the sort. It's nothing but a dishonest segue into listing the author's favourite merits of Smalltalk/Pharos then briefly mentioning the programming competition. No dissection of existing approaches to programming language evangelisation; no analyses of successful approaches and lessons drawn from those with lesser success; no examination of the correlation between a programming language's long term succes and strong community-based evangelisation and/or support from a major, well-known player in the IT industry. None of that. The mention of the competition is literally in the last two paragraphs, the last of which is only one sentence. Let's be honest: this isn't really an article at all. It's clickbait, and we've all been had. It attempts to write a cheque it can't cash.
    - louiscyphre 7y ago
      > No dissection of existing approaches to programming language evangelisation; no analyses of successful approaches and lessons drawn from those with lesser success; no examination of the correlation between a programming language's long term succes and strong community-based evangelisation and/or support from a major, well-known player in the IT industry. That was your expectation, not mine. You were led to believe one thing; I interpreted this article differently. Sure, for some people, the title could be seen as clickbait. I didn't see it that way. The author did present information, just not the information that you wanted. He pointed out that most language evangelization depends on technical publications and GitHub repos, and that this hasn't produced the desired outcome. That's practically axiomatic! Just look at where Clojure, Crystal, Elixir, F#, Haskell, Idris, Julia, Nim, Pony, and Ring are. They're still struggling for relevancy. In the third paragraph, he states: "I’m a Smalltalk evangelist and Pharo is one of these languages." There's nothing dishonest here. He's presenting Pharo and the programming competition as a sample case study. Once you dive into the linked article, you learn all you need to know about the competition.
dleslie 7y ago
For starters: when blogging about the language it is good practice to always link directly to the primary resource for it.
- louiscyphre 7y ago
  Here are some good resources: https://smalltalk.tech.blog/resources/ https://smalltalk.tech.blog/resources/ . It's a curated list.
_wldu 7y ago
Languages should stand or fall on their own technical merits. If you have to try and convince someone that language X is good (or bad), there is probably something not quite right. I hated Go when it first came out. I grew tired of hearing about it. My friends tried to get me to use it. I refused. One day, I needed to write some highly concurrent code, read about Go Routines, tried it and was hooked. I've been using it ever since. No amount of selling/proselytizing could convince me (nor should it). The language itself did when I took a serious look at it.
- lokedhs 7y ago
  But would you have tried it if your friends weren't trying to get you to try it?
  - AnimalMuppet 7y ago
    Possibly. Possibly even sooner; some of us are stubborn like that. But would _wldu have tried Go if he/she had never heard of it, and had no idea what features it had? Probably not; it's really hard to choose what you don't know exists.
- ivanbakel 7y ago
  >Languages should stand or fall on their own technical merits. A nice sentiment, but not reflected in reality. It's valuable to evangelise languages because 1. better awareness of their novel features can pressure more widely-used languages to adopt those features - like the addition of lambdas to Java, Python, etc. 2. otherwise you risk being stuck with whatever people know, forever. "Lack of fluency" is a technical demerit from the perspective of a project lead.
- nindalf 7y ago
  A language is a product, like any other. Before it can be used, it needs to be noticed by it's target audience. And to be noticed, it needs to be mentioned. Your own example demonstrates this. If none of your friends had ever mentioned Go to you, and no one had ever evangelised it, how would you have known that it's a good fit for that problem?
phtrivier 7y ago
Can someone with actual real-life in-production-for-a-while in-an-actual-company-with-annoying-customers-who-change-mind-all-the-times tell me about the refactoring story in Smalltalk ? Sure, I know the IDE can change the signature of a function, and stuff like that, but is it enough to actually do broad refactorings with any level of confidence ("broad" meaning "the kind where you realize the next feature requests invalidate most of your previous design, as happens pretty much every time you get a new feature request ?") Or are you still at the mercy of a whatever the Smalltalk version of a runtime error is, whenever you have - god forbid - made a typo somwhere ? I'm deeply hating a certain "pretty fashionable" dynamic langage (that will charitably remain unnamed) for this kind of reason, and I'm not going to buy the "Supreme productivity" claim anymore from any language that requires me to double check every function call just in case I mispelled a word.
- 7777fps 7y ago
  On this note, I still haven't found a language that does broad refactoring as well as C# (with resharper) does. From method extraction, to module, namespace, function renaming, to adding parameters to functions, it just takes care of it. My suspicion is that Java does it as well (but I don't have experience with it), but every other language I've tried lags far behind it. It's been really frustrating to be really getting into something then tripped up because it doesn't understand that when you're renaming Foo to Bar you also want foo.ext to become bar.ext. Or when you want to make foo(a,b,c) become foo(b,c) that it's the first parameter that needs removing (automatically) from all calls. Or even when transforming foo(a,b,c) to bar(b,c,d) that it can fix the calls with combined re-move and add parameter instructions. Some languages are starting to catch up, but I've seen nothing that has come close to the productivity that C# has delivered specifically with respect to refactoring. Can anyone recommend other language / IDE combinations that can deliver that kind of productivity? (And I don't want to get into a discussion about whether that's misplaced productivity because it's better to write in a way that doesn't need re-writing and re-naming things all the time, because you might be right but it's one of those times that being right doesn't change the reality of the work environment.)
  - ses1984 7y ago
unlinked_dll 7y ago
The author gets you with some Pharo evangelizing in there, sneaky. I'd really like someone from the Rust community (steveklabnik?) to write a history of the language/community and what decisions they took to grow. There's social and technical stuff that got people to go out and evangelize, which is half the battle - what they've really succeeded at is getting people to listen.
- tasogare 7y ago
  Frankly, Rust is not the example I would take about successful evanglization: the numerous Rewrite It In Rust (RIIC) posts, the ones asking on an inquisitional tone why the project haven't been written in rust, or those who changed the topic to rust in unrelated discussion (that's literally trolling) that is happening in a lot of threads here are really off-putting.
  - unlinked_dll 7y ago
    I mean my point was that it seemed to have worked. It's been awhile since I've seen RIIR posts or the dumb evangelism. More often I see comments like "this wouldn't have been a bug if you wrote it in Rust" which is usually accurate and engages compelling discussion.
    - saagarjha 7y ago
      > More often I see comments like "this wouldn't have been a bug if you wrote it in Rust" which is usually accurate and engages compelling discussion. It's usually accurate, but it rarely spurs compelling discussion in my experience. Whether it's inertia or actual pigheadedness, smugly suggesting that they could have "just" rewritten their software in Rust and they wouldn't have their day ruined doesn't invite the best kind of discussion, considering that the people involved are either just coming out of the bad day or tend to underestimate the costs of switching.
  - raphlinus 7y ago
    I have a "Rust Evangelism Strike Force" laptop sticker, but I will caution: the more aggressive evangelism stuff that you cite here is not coming from the core team or people who actually build the Rust ecosystem.
dustingetz 7y ago
PHP did not need anybody to evangelize it
- guggle 7y ago
  cheap hosters did.
- msla 7y ago
  PHP was evangelized by every website which mentioned it was built in it, including having URLs ending in ".php". Similarly, C and shell were evangelized by every Unix installation, Javascript was evangelized by every website which used it, BASIC was evangelized by innumerable microcomputers which had a BASIC interpreter instead of an OS... the point is, the best evangelism is to tie the language to something useful. Make the language the way you get at the functionality of that thing. Python and R are both evangelized by tons of pre-written code which you can access most conveniently from those languages, for example. Smalltalk is the language you use to get the value out of Smalltalk systems. The problem is that, for a lot of people, there's no next step: What do you use the Smalltalk system for? Very few have an answer. The alternative is to make your language a better way to get value out of an existing system. Python spread in part by doing this to shell and Perl, and Perl spread in part by doing it to shell. Python isn't just a better Unix scripting language, because of its libraries, much like how Perl isn't just a better shell because of its libraries. However, it's one reason Python and Perl spread so effectively. Now, Go is trying to do it to Python and Rust is trying to do it to C++. So tie your language to something big, or focus on displacing a language already tied to something big.
  - louiscyphre 7y ago
    > What do you use the Smalltalk system for? Very few have an answer. I have... You use Smalltalk for back-end web development with tools like Seaside (http://seaside.st/ http://seaside.st/ ) and Teapot. You use Smalltalk for front-end web development with tools like Amber and PharoJS. You use Smalltalk for data science with tools like PolyMath library, Roassal data visualization (https://youtu.be/R2rLr7Z1b8Y https://youtu.be/R2rLr7Z1b8Y ), and Moose analytics platform (https://moosetechnology.org/ https://moosetechnology.org/ ). You use Smalltalk for machine learning with Pharo bindings for TensorFlow and Keras. You use Smalltalk for IoT applications with tools like PharoThings (https://github.com/pharo-iot/PharoThings https://github.com/pharo-iot/PharoThings ). You use Smalltalk for robotics with tools like PhaROS (http://car.mines-douai.fr/category/pharos/ http://car.mines-douai.fr/category/pharos/ ). You use Smalltalk for virtual reality like in this example: https://youtu.be/b4nNtN7XBi8 https://youtu.be/b4nNtN7XBi8 . You use Smalltalk for mobile software with tools like Apache Cordova. You use Smalltalk for desktop software with the Spec library (https://books.pharo.org/spec-tutorial/ https://books.pharo.org/spec-tutorial/ ). Enterprises have been using Smalltalk for decades. It's especially popular in the financial industry. It's also used in manufacturing, utilities, transportation, government, etc. Lam Research is worth mentioning. This company is a vital link in the global supply chain. The electronic components in your smartphones, PCs, laptops, etc. started out as silicon wafers fabricated by Lam machines controlled by Smalltalk. You owe your digital existence to Smalltalk! The U.S. joint military even used Smalltalk to write a million-line battle simulator called JWARS. It actually outperformed a similar software called STORM written in C++ by the U.S. Air Force. JWARS was decommissioned in 2010 due to budget cuts. Did you know that Smalltalk is also used for system scripting just like Python and Perl? With GNU Smalltalk and Pharo (in command line mode), this is common practice. There are very few programming languages that are as flexible and versatile as Smalltalk.
unnouinceput 7y ago
Does it has cross-platform? One codebase, multiple targets? That's how you evangelize any programming language. In today's environment where the customer wants his solution to work on all devices, the programming language that has the least (zero might be impossible) quirks when targeting different OS'es wins my heart. So far, IMO, there are zero programming languages that do this. Java comes closest but is like only half-way there, rest are either lagging behind or even don't even approach this. Also I hate Java, but that's my personal choice.
- smalltalkcoder 7y ago
  Absolutely. Pharo is much like Java: it's VM-based, so Pharo software will run on any platform that has a Pharo VM. This includes Windows, macOS, and Linux. And if you use PharoJS, which transpiles to JS, the same software will run in any web browser, and on mobile devices (using Apache Cordova).
  - unnouinceput 7y ago
    Maybe I was not detail oriented in my above comment. You see, there are plenty of programming languages that have multiple targets/cross-platform capabilities but when it comes to serious implementation users want to have same experience everywhere. For example, dialogs. Choose a file, right? I mean how hard can it be to select a picture and view it on screen. Well, Android is non-blocking while Windows can be modal blocking. So in Windows it's easy to show a file dialog to select a file then your code goes to put it on screen. Well, good luck doing that in Android. There you have to split your code in several routines that chain each other in order to achieve same effect. Which leads to different code either split by files or surrounded by compiler switches. Boom!! Not what I want!! I know how to do that in dozens of so called cross-platform programming languages. What I want is one call "ShowDialog" implemented at programming language level, not 3rd party, not my code splitted by compiler switches, that behaves the same in all targets. That, my friend, is what I meant by zero programming languages doing this currently.
- brabel 7y ago
  > the programming language that has the least (zero might be impossible) quirks when targeting different OS'es wins my heart. Two languages come to mind (though I think this is an unpopular opinion, I will try anyway): * Dart (runs really well and cross-platform on desktop, mobile and web) * Haxe (because it can compile to pretty much anything: C++, Java, JS...)
zapzupnz 7y ago
This entire article is nothing but evangelisation for Pharo. Misleading title, worthless post. I’m not surprised either. The author only ever writes Pharo evangelicals that consistently fail to demonstrate any of the supposed benefits; we’re always to simply believe what is said. Any body can show me buzz words. Nobody gets points for buzz words, not even for effort. That’s patently not how one promotes a programming language.
- smalltalkcoder 7y ago
  Evangelization is "preaching"; it's essentially advertising or marketing. There's no one way to preach or advertise. One can take a number of different approaches. Presenting technical information is one way, the most common way. It's how most languages are promoted. But most languages never succeed with this approach. Most languages never gain much mind share. So the author has taken another approach, something that is seldom attempted. The programming competition is an original and clever idea. I'm not sure how one can "demonstrate the benefits" of a programming language. Most languages have been used successfully in software projects (e.g., Crystal, Elixir, F#, Haxe, Julia, Nim, etc.). Does trotting out these projects prove anything?
  - zapzupnz 7y ago
    > There is no one way to preach or advertise But writing articles about a particular premise then barely discussing it or offering a solution, that's not it. > The programming competition is an original and clever idea It's not that original; competitions for languages, especially to develop particular solutions in a language, happen all the time. That's how plenty of lesser-used languages wind up with some of the 'batteries' that erstwhile appeared to be missing. It's a clever idea, yes. However, mention of the competition is also barely a paragraph's worth of text's mention at the bottom of a blog post that, I re-emphasise, gives the impression of discussing programming language evangelisation but then almost immediately makes no interesting remarks on the topic other than "some programming languages are still obscure", immediately launches into a poorly-demonstrated list of reasons why Pharo is apparently so good, and then a sentence or two about a competition. The competition isn't even really discussed, how well it did, how many participants it drew, what came out of it. As it states, the success of the experiment is yet to be determined — which makes mention of it even more confusing. We have a blog post with a broad, general scope that finishes with no real conclusion to its own thesis. This isn't advertising, this is spam. > I'm not sure how one can "demonstrate the benefits" of a programming language - Code examples (like GTK+ new website) - Interactive widgets on websites (like ReasonML's website) - Demonstrations of how a specific idea is better/more easily/more stably solved using that language (like most functional programming languages' websites) - Interviews, often as blog posts or podcasts, with developers who've deployed applications or services backed by the language There are plenty of ways that plenty of languages (and other technological artefacts, such as libraries and runtimes) can demonstrate their benefits, many more than I've listed. Anything has to be better than saying "yes, it's better" without being able to reasonably demonstrate how or why to the satisfaction of people whose existing set of tools already ably work for them. > Does trotting out these projects prove anything? Yes, actually. It does. Most programming websites are falling over themselves to demonstrate that their languages are successfully used and deployed in all sorts of situations, some more domain-specific than others. It proves that something not only is ready for the big time but also can do it something so much better than competing solutions — and, again, will demonstrate how or why.
deleted 7y ago
[deleted]
estebanlor 7y ago
I have to say this: I am the architect of Pharo (bah, the guy who has the responsibility of putting the pieces together and handle the releases). While I cannot do anything about it, I do not feel comfortable (and I know a lot if not all the members of the "core team" either) with this kind of "evangelisation". We love our little environment, and we certainly believe it has merits enough to be considered a player in the language ecosystem. We do our language with passion and conviction, but also with respect for other languages and programmers. While the author has the right to do as he thinks is the best, please consider this is not how the team developing Pharo thinks and act.
- smalltalkcoder 7y ago
  This article is mainly about the programming competition. What's wrong with that kind of evangelism? I think it's a great idea. It certainly attracts attention to Smalltalk (Pharo), a relatively obscure language. If you're grousing about the author's comparison to other languages, he's not showing disrespect by pointing out that their approach to language promotion hasn't produced the desired outcome. He's simply stating the truth.
  - xkriva11 7y ago
    Dear Mr Eng (or louiscyphre or smalltalkcoder), please stop using alternative accounts to pretend that others like your articles.
    - smalltalkcoder 7y ago
      I am not Richard Eng. Why would you think that anyone who supports Smalltalk can only be him? Do you really believe there is only one Smalltalk fan throughout the world? Richard is the most prolific promoter of Smalltalk in years. So I support and applaud his efforts. Why is this so difficult to accept?

37 points by louiscyphre 7y ago

deleted 7y ago

[deleted]

This article has only one real tip: create a high school programming contest for it. The rest is evangelizing a specific language itself, which I won't mention to avoid fueling the gimmick. I think we've been had. In general programming language preferences are subjective. We all think different. I've been in many many debates over language merit. The only language that would truly make one happy is one custom fit for his/her own head. I personally want something that leverages the database more so I don't have to do data chomping in code, nor reinvent the schema in code (DRY). I'd also like custom block-scoping so that one is not stuck choosing between OOP or FP etc. A code-block's scope would be programmer-defined. You could roll our own control and class-like constructs. Actually some languages are meta (bend-able) enough to reshape almost any way you want, but then in a team environment, you have to face others' custom mind-fit code, which defeats the purpose.

codr7 7y ago
One way that I feel comfortable with is publishing clear, real life-ish examples of what can be accomplished in the language by playing on it's strengths. Debating merits never really leads anywhere, all languages have strengths and weaknesses, all languages are compromises in some respect. I've put quite some effort into the DRY database schema problem over the years. The only reasonable way forward that I've found is defining the schema in code and creating the database from that definition. SQL is a definitely more primitive and limited than most programming languages, so it makes perfect sense to generate it. And the only way to truly custom fit a language is to create it [0]. [0] https://github.com/codr7/gfoo https://github.com/codr7/gfoo
- tabtab 7y ago
  Rather than rely on SQL, why not put the common info in tables? A "data dictionary" (DD). If tools can extract or sync that up to the actual schema, that's a great bonus, but is not a prerequisite. Using things POC annotations is ugly and hard to track. And we don't have to rely on the DD to do everything. Of course intricate business logic should be in app code, but app code shouldn't reinvent the obvious things like minimum length ("required"), max length, field description, synopsis (longer "help"), display order, key type (primary, foreign) and their related "look-up" references, etc. I've found that if the DD results can be intercepted by the program, then it's more flexible. It should have an event that allows the DD attributes to be programmatically altered per screen, and then another event to modify or remove the actual HTML and/or SQL generated from the those attributes. I call it "staged rendering". This allows the DD to do 90% of the grunt work, but not limit local customization. Local customization has been the most common bottleneck of past DD-based attempts. I like it when computers do the grunt work; that's what they were invented for. Our current common CRUD stacks violate data-related D.R.Y. up the wazoo and nobody seems to care as long as they get a paycheck. Auto code generation is only a half solution because once you alter the copies, you can't rely on generators anymore: they wipe out your custom code.
  - codr7 7y ago
    Interesting. I never use annotations in my own tools, I add first class abstractions for whatever database features I need and free form records to shuffle data. So there will be something called a Table, with Columns and Keys. It's not so much reinventing as bridging, an FFI doesn't reinvent the library it imports. And yes, that means you can't modify the database from the bottom any more. But you're not losing any power, since any random programming language is more flexible and convenient. Most databases come with some kind of built-in DD, I've used them in Firebird & Postgres to read primary- and foreign keys while I was still investigating the approach. But it never really clicks for me, because the database is not the software, it's where the software stores its data. Tying application logic and presentation to the relational structure of the data just doesn't make any sense to me.
kthielen 7y ago
I think that part of the problem is to define data structures in a way that can be produced and consumed in multiple languages, algebraic data types are a good "least common denominator" for this. Also w.r.t. reinventing the schema for databases, I have got a lot of mileage out of deriving the schema from code. Shameless plug, I have this little project (https://github.com/Morgan-Stanley/hobbes/ https://github.com/Morgan-Stanley/hobbes/) where we have a self-contained header-only library to push structured data out of process with minimal latency, query data concurrently with a Haskell-like PL. It works well for our kinds of systems (millions of orders per day, ~1 billion market data ticks, structured log data from multiple systems involved, ...).
- tabtab 7y ago
  Attributes are usually easier to share than functions and algorithms. That's why I suggest using "data dictionaries" nearby. Most common CRUD idioms are readily attribute-able such that we don't need Turing Complete sub-languages for majority of them. We just need useful code "hooks" to customize when needed, which is the usual bottleneck of attribute-driven development.
louiscyphre 7y ago
> This article has only one real tip: create a high school programming contest for it. Yes, but this "tip" was demonstrated by an example. The example is a Pharo-based programming competition, so it's reasonable to say a few words about Pharo. Otherwise, the article would be pretty darn brief!
- zapzupnz 7y ago
  > Otherwise, the article would be pretty darn brief! It is pretty darn brief. The title and first few paragraphs would lead one to believe that the article is going to be about programming language evangelisation. Instead, it's nothing of the sort. It's nothing but a dishonest segue into listing the author's favourite merits of Smalltalk/Pharos then briefly mentioning the programming competition. No dissection of existing approaches to programming language evangelisation; no analyses of successful approaches and lessons drawn from those with lesser success; no examination of the correlation between a programming language's long term succes and strong community-based evangelisation and/or support from a major, well-known player in the IT industry. None of that. The mention of the competition is literally in the last two paragraphs, the last of which is only one sentence. Let's be honest: this isn't really an article at all. It's clickbait, and we've all been had. It attempts to write a cheque it can't cash.
  - louiscyphre 7y ago
    > No dissection of existing approaches to programming language evangelisation; no analyses of successful approaches and lessons drawn from those with lesser success; no examination of the correlation between a programming language's long term succes and strong community-based evangelisation and/or support from a major, well-known player in the IT industry. That was your expectation, not mine. You were led to believe one thing; I interpreted this article differently. Sure, for some people, the title could be seen as clickbait. I didn't see it that way. The author did present information, just not the information that you wanted. He pointed out that most language evangelization depends on technical publications and GitHub repos, and that this hasn't produced the desired outcome. That's practically axiomatic! Just look at where Clojure, Crystal, Elixir, F#, Haskell, Idris, Julia, Nim, Pony, and Ring are. They're still struggling for relevancy. In the third paragraph, he states: "I’m a Smalltalk evangelist and Pharo is one of these languages." There's nothing dishonest here. He's presenting Pharo and the programming competition as a sample case study. Once you dive into the linked article, you learn all you need to know about the competition.

dleslie 7y ago

For starters: when blogging about the language it is good practice to always link directly to the primary resource for it.

louiscyphre 7y ago
Here are some good resources: https://smalltalk.tech.blog/resources/ https://smalltalk.tech.blog/resources/ . It's a curated list.

_wldu 7y ago

Languages should stand or fall on their own technical merits. If you have to try and convince someone that language X is good (or bad), there is probably something not quite right. I hated Go when it first came out. I grew tired of hearing about it. My friends tried to get me to use it. I refused. One day, I needed to write some highly concurrent code, read about Go Routines, tried it and was hooked. I've been using it ever since. No amount of selling/proselytizing could convince me (nor should it). The language itself did when I took a serious look at it.

lokedhs 7y ago
But would you have tried it if your friends weren't trying to get you to try it?
- AnimalMuppet 7y ago
  Possibly. Possibly even sooner; some of us are stubborn like that. But would _wldu have tried Go if he/she had never heard of it, and had no idea what features it had? Probably not; it's really hard to choose what you don't know exists.
ivanbakel 7y ago
>Languages should stand or fall on their own technical merits. A nice sentiment, but not reflected in reality. It's valuable to evangelise languages because 1. better awareness of their novel features can pressure more widely-used languages to adopt those features - like the addition of lambdas to Java, Python, etc. 2. otherwise you risk being stuck with whatever people know, forever. "Lack of fluency" is a technical demerit from the perspective of a project lead.
nindalf 7y ago
A language is a product, like any other. Before it can be used, it needs to be noticed by it's target audience. And to be noticed, it needs to be mentioned. Your own example demonstrates this. If none of your friends had ever mentioned Go to you, and no one had ever evangelised it, how would you have known that it's a good fit for that problem?

phtrivier 7y ago

Can someone with actual real-life in-production-for-a-while in-an-actual-company-with-annoying-customers-who-change-mind-all-the-times tell me about the refactoring story in Smalltalk ? Sure, I know the IDE can change the signature of a function, and stuff like that, but is it enough to actually do broad refactorings with any level of confidence ("broad" meaning "the kind where you realize the next feature requests invalidate most of your previous design, as happens pretty much every time you get a new feature request ?") Or are you still at the mercy of a whatever the Smalltalk version of a runtime error is, whenever you have - god forbid - made a typo somwhere ? I'm deeply hating a certain "pretty fashionable" dynamic langage (that will charitably remain unnamed) for this kind of reason, and I'm not going to buy the "Supreme productivity" claim anymore from any language that requires me to double check every function call just in case I mispelled a word.

7777fps 7y ago
On this note, I still haven't found a language that does broad refactoring as well as C# (with resharper) does. From method extraction, to module, namespace, function renaming, to adding parameters to functions, it just takes care of it. My suspicion is that Java does it as well (but I don't have experience with it), but every other language I've tried lags far behind it. It's been really frustrating to be really getting into something then tripped up because it doesn't understand that when you're renaming Foo to Bar you also want foo.ext to become bar.ext. Or when you want to make foo(a,b,c) become foo(b,c) that it's the first parameter that needs removing (automatically) from all calls. Or even when transforming foo(a,b,c) to bar(b,c,d) that it can fix the calls with combined re-move and add parameter instructions. Some languages are starting to catch up, but I've seen nothing that has come close to the productivity that C# has delivered specifically with respect to refactoring. Can anyone recommend other language / IDE combinations that can deliver that kind of productivity? (And I don't want to get into a discussion about whether that's misplaced productivity because it's better to write in a way that doesn't need re-writing and re-naming things all the time, because you might be right but it's one of those times that being right doesn't change the reality of the work environment.)
- ses1984 7y ago

unlinked_dll 7y ago

The author gets you with some Pharo evangelizing in there, sneaky. I'd really like someone from the Rust community (steveklabnik?) to write a history of the language/community and what decisions they took to grow. There's social and technical stuff that got people to go out and evangelize, which is half the battle - what they've really succeeded at is getting people to listen.

tasogare 7y ago
Frankly, Rust is not the example I would take about successful evanglization: the numerous Rewrite It In Rust (RIIC) posts, the ones asking on an inquisitional tone why the project haven't been written in rust, or those who changed the topic to rust in unrelated discussion (that's literally trolling) that is happening in a lot of threads here are really off-putting.
- unlinked_dll 7y ago
  I mean my point was that it seemed to have worked. It's been awhile since I've seen RIIR posts or the dumb evangelism. More often I see comments like "this wouldn't have been a bug if you wrote it in Rust" which is usually accurate and engages compelling discussion.
  - saagarjha 7y ago
    > More often I see comments like "this wouldn't have been a bug if you wrote it in Rust" which is usually accurate and engages compelling discussion. It's usually accurate, but it rarely spurs compelling discussion in my experience. Whether it's inertia or actual pigheadedness, smugly suggesting that they could have "just" rewritten their software in Rust and they wouldn't have their day ruined doesn't invite the best kind of discussion, considering that the people involved are either just coming out of the bad day or tend to underestimate the costs of switching.
- raphlinus 7y ago
  I have a "Rust Evangelism Strike Force" laptop sticker, but I will caution: the more aggressive evangelism stuff that you cite here is not coming from the core team or people who actually build the Rust ecosystem.

dustingetz 7y ago

PHP did not need anybody to evangelize it

guggle 7y ago
cheap hosters did.
msla 7y ago
PHP was evangelized by every website which mentioned it was built in it, including having URLs ending in ".php". Similarly, C and shell were evangelized by every Unix installation, Javascript was evangelized by every website which used it, BASIC was evangelized by innumerable microcomputers which had a BASIC interpreter instead of an OS... the point is, the best evangelism is to tie the language to something useful. Make the language the way you get at the functionality of that thing. Python and R are both evangelized by tons of pre-written code which you can access most conveniently from those languages, for example. Smalltalk is the language you use to get the value out of Smalltalk systems. The problem is that, for a lot of people, there's no next step: What do you use the Smalltalk system for? Very few have an answer. The alternative is to make your language a better way to get value out of an existing system. Python spread in part by doing this to shell and Perl, and Perl spread in part by doing it to shell. Python isn't just a better Unix scripting language, because of its libraries, much like how Perl isn't just a better shell because of its libraries. However, it's one reason Python and Perl spread so effectively. Now, Go is trying to do it to Python and Rust is trying to do it to C++. So tie your language to something big, or focus on displacing a language already tied to something big.
- louiscyphre 7y ago
  > What do you use the Smalltalk system for? Very few have an answer. I have... You use Smalltalk for back-end web development with tools like Seaside (http://seaside.st/ http://seaside.st/ ) and Teapot. You use Smalltalk for front-end web development with tools like Amber and PharoJS. You use Smalltalk for data science with tools like PolyMath library, Roassal data visualization (https://youtu.be/R2rLr7Z1b8Y https://youtu.be/R2rLr7Z1b8Y ), and Moose analytics platform (https://moosetechnology.org/ https://moosetechnology.org/ ). You use Smalltalk for machine learning with Pharo bindings for TensorFlow and Keras. You use Smalltalk for IoT applications with tools like PharoThings (https://github.com/pharo-iot/PharoThings https://github.com/pharo-iot/PharoThings ). You use Smalltalk for robotics with tools like PhaROS (http://car.mines-douai.fr/category/pharos/ http://car.mines-douai.fr/category/pharos/ ). You use Smalltalk for virtual reality like in this example: https://youtu.be/b4nNtN7XBi8 https://youtu.be/b4nNtN7XBi8 . You use Smalltalk for mobile software with tools like Apache Cordova. You use Smalltalk for desktop software with the Spec library (https://books.pharo.org/spec-tutorial/ https://books.pharo.org/spec-tutorial/ ). Enterprises have been using Smalltalk for decades. It's especially popular in the financial industry. It's also used in manufacturing, utilities, transportation, government, etc. Lam Research is worth mentioning. This company is a vital link in the global supply chain. The electronic components in your smartphones, PCs, laptops, etc. started out as silicon wafers fabricated by Lam machines controlled by Smalltalk. You owe your digital existence to Smalltalk! The U.S. joint military even used Smalltalk to write a million-line battle simulator called JWARS. It actually outperformed a similar software called STORM written in C++ by the U.S. Air Force. JWARS was decommissioned in 2010 due to budget cuts. Did you know that Smalltalk is also used for system scripting just like Python and Perl? With GNU Smalltalk and Pharo (in command line mode), this is common practice. There are very few programming languages that are as flexible and versatile as Smalltalk.

unnouinceput 7y ago

Does it has cross-platform? One codebase, multiple targets? That's how you evangelize any programming language. In today's environment where the customer wants his solution to work on all devices, the programming language that has the least (zero might be impossible) quirks when targeting different OS'es wins my heart. So far, IMO, there are zero programming languages that do this. Java comes closest but is like only half-way there, rest are either lagging behind or even don't even approach this. Also I hate Java, but that's my personal choice.

smalltalkcoder 7y ago
Absolutely. Pharo is much like Java: it's VM-based, so Pharo software will run on any platform that has a Pharo VM. This includes Windows, macOS, and Linux. And if you use PharoJS, which transpiles to JS, the same software will run in any web browser, and on mobile devices (using Apache Cordova).
- unnouinceput 7y ago
  Maybe I was not detail oriented in my above comment. You see, there are plenty of programming languages that have multiple targets/cross-platform capabilities but when it comes to serious implementation users want to have same experience everywhere. For example, dialogs. Choose a file, right? I mean how hard can it be to select a picture and view it on screen. Well, Android is non-blocking while Windows can be modal blocking. So in Windows it's easy to show a file dialog to select a file then your code goes to put it on screen. Well, good luck doing that in Android. There you have to split your code in several routines that chain each other in order to achieve same effect. Which leads to different code either split by files or surrounded by compiler switches. Boom!! Not what I want!! I know how to do that in dozens of so called cross-platform programming languages. What I want is one call "ShowDialog" implemented at programming language level, not 3rd party, not my code splitted by compiler switches, that behaves the same in all targets. That, my friend, is what I meant by zero programming languages doing this currently.
brabel 7y ago
> the programming language that has the least (zero might be impossible) quirks when targeting different OS'es wins my heart. Two languages come to mind (though I think this is an unpopular opinion, I will try anyway): * Dart (runs really well and cross-platform on desktop, mobile and web) * Haxe (because it can compile to pretty much anything: C++, Java, JS...)

zapzupnz 7y ago

This entire article is nothing but evangelisation for Pharo. Misleading title, worthless post. I’m not surprised either. The author only ever writes Pharo evangelicals that consistently fail to demonstrate any of the supposed benefits; we’re always to simply believe what is said. Any body can show me buzz words. Nobody gets points for buzz words, not even for effort. That’s patently not how one promotes a programming language.

smalltalkcoder 7y ago
Evangelization is "preaching"; it's essentially advertising or marketing. There's no one way to preach or advertise. One can take a number of different approaches. Presenting technical information is one way, the most common way. It's how most languages are promoted. But most languages never succeed with this approach. Most languages never gain much mind share. So the author has taken another approach, something that is seldom attempted. The programming competition is an original and clever idea. I'm not sure how one can "demonstrate the benefits" of a programming language. Most languages have been used successfully in software projects (e.g., Crystal, Elixir, F#, Haxe, Julia, Nim, etc.). Does trotting out these projects prove anything?
- zapzupnz 7y ago
  > There is no one way to preach or advertise But writing articles about a particular premise then barely discussing it or offering a solution, that's not it. > The programming competition is an original and clever idea It's not that original; competitions for languages, especially to develop particular solutions in a language, happen all the time. That's how plenty of lesser-used languages wind up with some of the 'batteries' that erstwhile appeared to be missing. It's a clever idea, yes. However, mention of the competition is also barely a paragraph's worth of text's mention at the bottom of a blog post that, I re-emphasise, gives the impression of discussing programming language evangelisation but then almost immediately makes no interesting remarks on the topic other than "some programming languages are still obscure", immediately launches into a poorly-demonstrated list of reasons why Pharo is apparently so good, and then a sentence or two about a competition. The competition isn't even really discussed, how well it did, how many participants it drew, what came out of it. As it states, the success of the experiment is yet to be determined — which makes mention of it even more confusing. We have a blog post with a broad, general scope that finishes with no real conclusion to its own thesis. This isn't advertising, this is spam. > I'm not sure how one can "demonstrate the benefits" of a programming language - Code examples (like GTK+ new website) - Interactive widgets on websites (like ReasonML's website) - Demonstrations of how a specific idea is better/more easily/more stably solved using that language (like most functional programming languages' websites) - Interviews, often as blog posts or podcasts, with developers who've deployed applications or services backed by the language There are plenty of ways that plenty of languages (and other technological artefacts, such as libraries and runtimes) can demonstrate their benefits, many more than I've listed. Anything has to be better than saying "yes, it's better" without being able to reasonably demonstrate how or why to the satisfaction of people whose existing set of tools already ably work for them. > Does trotting out these projects prove anything? Yes, actually. It does. Most programming websites are falling over themselves to demonstrate that their languages are successfully used and deployed in all sorts of situations, some more domain-specific than others. It proves that something not only is ready for the big time but also can do it something so much better than competing solutions — and, again, will demonstrate how or why.

deleted 7y ago

[deleted]

estebanlor 7y ago

I have to say this: I am the architect of Pharo (bah, the guy who has the responsibility of putting the pieces together and handle the releases). While I cannot do anything about it, I do not feel comfortable (and I know a lot if not all the members of the "core team" either) with this kind of "evangelisation". We love our little environment, and we certainly believe it has merits enough to be considered a player in the language ecosystem. We do our language with passion and conviction, but also with respect for other languages and programmers. While the author has the right to do as he thinks is the best, please consider this is not how the team developing Pharo thinks and act.

smalltalkcoder 7y ago
This article is mainly about the programming competition. What's wrong with that kind of evangelism? I think it's a great idea. It certainly attracts attention to Smalltalk (Pharo), a relatively obscure language. If you're grousing about the author's comparison to other languages, he's not showing disrespect by pointing out that their approach to language promotion hasn't produced the desired outcome. He's simply stating the truth.
- xkriva11 7y ago
  Dear Mr Eng (or louiscyphre or smalltalkcoder), please stop using alternative accounts to pretend that others like your articles.
  - smalltalkcoder 7y ago
    I am not Richard Eng. Why would you think that anyone who supports Smalltalk can only be him? Do you really believe there is only one Smalltalk fan throughout the world? Richard is the most prolific promoter of Smalltalk in years. So I support and applaud his efforts. Why is this so difficult to accept?