I can read C++ and Java but I can’t read Smalltalk (2000) [pdf]
eli.sdsu.edu
eli.sdsu.edu
To be honest, I find this is actually the hardest thing I grapple with when I look at mathematics that I'm not familiar with. A lot of times the concept and the equation are simple, but if I'm not familiar with what a specific greek letter is supposed to represent it's completely impenetrable. Not that I'm saying we have to change math, but I always found that was the biggest obstacle for me.
A few years ago (on sort of a whim?) I read a ML science paper without first having much of the foundational knowledge; I'd end up having to go off on more than a few Google dives per paragraph, just to understand what they were talking about.
But you can't Google an equation, or a symbol in an equation - at least I couldn't, and get meaningful results.
Sometimes they are nice enough to say "we use random squiggly arrow to mean x", but then you need to keep a table of symbols on the side to even read the paper.
Other times they just reuse "common" symbols and expect you to know, even though that symbol has been used for more than one purpose over time.
It's all very tiresome.
That's pretty much the norm with scientific publications, no? They're intended to be read by people with advanced degrees in the field.
We should have iconographic dictionaries for Math.
Interestingly, the first Smalltalk, Smalltalk-72, used loads of symbols.[0] Introducing a new variable used an index finger symbol. Evaluating a message used an opened eyeball. The "turtle" was represented by something looking like a smiley face. There's a working emulator of Smalltalk-72 on Dan Ingalls' website, and I'd recommend playing around with it.[1] They really embraced the "everything is messages" thing, and couldn't figure out how to optimize it on their hardware (since the language is frankly way too powerful and not amenable to static analysis). If they could have seen the utility of something like a JIT, the future might have turned out differently, but as it happens, the Smalltalk variant Self was the first highly-efficient one, almost 20 years after Smalltalk-72.
Sun later cannibalized the Self team to have them focus on Java performance, and the result was the HotSpot VM, which in some ways saved Java from being a failure.
[0] http://www.esug.org/data/HistoricalDocuments/Smalltalk72/Sma...
Smalltalk-80 was the language IBM trained their consultants to use.
But it was unfortunatelly discarded as soon as Xerox published Smalltalk-80.
https://archive.org/details/RosettaBrochure/RosettaBrochure/...
Yep, definitely one of the most readable out there.
> unreadable languages are languages that rely heavily on symbols.
Yes and no.
I actually find symbols useful for very common and mostly structural elements. As an extreme example, assignment as '←' or ':=' or '=' is much better than "assign to" or having to use special accessor methods/messages (leaving aside that these things should be dynamic).
And I actually like the way that Objective-C uses "-" to introduce instance methods, because they are so common and there is really not much else that could go there, except maybe a class method introduced via "+". Having to write "function" or "func" each time is just clutter, and non-sensical clutter because there is very little else that could go there, and certainly nothing user defined last I checked. C of course doesn't use anything at all, you just start writing the function return type and name.
Similar with "set" and "get" for property accessors in C#. Those just seem wrong at that location, though I don't really have a good alternative. I tried to use "=|" and "|=" in Objective-S (http://objective.st), but nope, not a good alternative. Although "|=" is pretty good for dataflow constraints / permanent assignments.
Similar with "at:" for indexed access in Smalltalk. While I appreciate the uniformity, the "[]" syntax really adds something here and is common enough for special syntax to make sense.
So anyway: names for semantic-bearing and user-defined constructs. Symbols for very common structural/architectural elements, where they can be made to make sense.
UPDATE: In many ways, this is a lot like natural language does it, though of course not identical. It would be awkward to have to write "full stop" or "this sentence ends here" at the end of every sentence. So: punctuation.
Most of the problems with that language, rightfully flagged in this article, are not as problematic when the code is read inside it's native environement.
25 years ago, a tight integration between the language and the IDE like that would have sounded great to me. Nowadays, though, it strikes me as a terrible, terrible flaw.
What's changed is the development of a collaborative development across the Internet, and a stronger emphasis on code review. So now, for a great many projects, the most important code reading typically happens outside the code's native environment. It's done in whatever least-common-denominator view you get in your team's code review tool.
For example if I add an additional usage to a global variable to a file, while someone else renames it in other files, git happily merges with no conflict.
Tighter language integration can help with that.
For example, I have seen cases with diffing where based on whatever algorithm, a very small logical change, (like moving a function up or down in the file along with a minor edit), creates a very confusing side by side diff based on whatever similar lines it think match up.
I would very much like for this not to be true, but there doesn’t seem to be a good solution.
With syntax trees in particular, it’s also frequently difficult to find even a single good option for what you would reasonably want a diff to be: last I checked rich-text diffs usable over arbitrary HTML (even sans CSS) still sucked in half the cases you’d want. Line- and word-based diffs over the source also suck, naturally, but at least they do so uniformly. It’s not an accident Stack Overflow will usually try to show you a rich-text diff when editing but will occasionally fall back to word-diffing the Markdown.
And a version control system needs to interoperate above all. Unlike, say, an IDE, and you do see attempts at semantic and even structured editing in IDEs.
/me continues to fantasize about interbreeding Paredit and Pijul one day
The terrible flaw, to me, sounds like it's the workflow that won't bother installing the right tools for code review. It's not like you're stuck with printouts or something where those tools aren't practical.
(If the IDEs or editors are lacking things needed for code review, then that's a problem, but it's not a problem inherent to the idea of tight integration.)
And from there you can use GitHub Codespace to "develop in a cloud-hosted, customizable environment" to run and debug.
To be clear, I'm talking about the VSCode app. Once you visit it they hijack the browser history and hitting back causes the entire app to reload, over and over again, until you manually drop down the history menu and jump 2+ pages back.
I realize now my comment sounded rude and pointed toward the parent (not at all the intent) - I can't edit it so here I am again.
The proposition here is that the IDE provides dev process tooling so you are in fact collaborating with your team, e.g. reviewing your code, but Github (Microsoft) and other centralized services are not necessary and not included in the activity. And yes, if AWS etc goes down, your IDEs will continue to work and you can continue to collaborate.
Smalltalk has always went in the amazing language to look for inspiration from. Commercial implementations were pretty pricey (I think in the thousands). Ultimately, smalltalk really fell out of favor because:
* Bad story on concurrency and multiprocessing.
* Wasn't really all that portable.
* Tightly bound with development environment.
* Resource hungry mostly due to being tightly bound to the ide, and many implementations required the IDE to ship with the product.
* Expensive
I learned a lot about object oriented development from playing with smalltalk, and was able to employ a lot of what I learned using Java, Python, C#, Objective C, and C++. To this day, you really see a lot of code editing and management concepts that started in smalltalk in your favorite IDE.
Mostly non-premptive lightweight concurrency (with the multiprocessor exception Actra)
> * Wasn't really all that portable.
iirc Just copying files from MacOS to MSWin to Unices was enough to port software.
> * Tightly bound with development environment.
That was considered to be a feature not a bug.
> Resource hungry mostly due to being tightly bound to the ide, and many implementations required the IDE to ship with the product.
The IDE could be stripped-out.
> * Expensive
Everything is expensive when the alternative is free-as-in-beer.
> Ultimately, smalltalk really fell out of favor because:
"The Rise and Fall of Commercial Smalltalk (2020)"
And then the fun starts —
https://www.researchgate.net/publication/3422160_Tools_for_m...
"Tools for making impossible changes - experiences with a tool for transforming large Smalltalk programs"
t.rotate (a, v); // Original
t rotate (a, v); // Who needs dot?
t rotate a, v; // Who needs brackets?
t rotate by: a around: v; // Who needs ambiguity?
t rotateBy: a around: v // This is Smalltalk
Also, you missed a step. Before "ambiguity":
t rotate by a around v; //Who needs commas?And yes, they probably could be used for other purposes. The names are mnemonics for "angle" (a) and "vector" (v). How you arrive at them and what you'd use them for could easily vary across a system.
t.rotate(around, rotateBy)
t rotateBy: point around:degrees
Compiler-enforced clarity rather than relying on every individual piece of client code to always name things well & never make a mistake.
t.rotate(a, v);
...
t rotateBy: a around: v
Objectively speaking (yeah right) there is no difference and both serve the same purpose. For whatever reason the first form is more visually and mentally pleasing to me.
If it was written by me it would be:
t.rotate(angle, around);
t.rotate a v
Alternatively if the rotate method uses named args:
t.rotate --by=a --around=v
(See toitlang.org).
t.rotate(a, v).translate(x, y).scale(w, h);
A better way to remove all the "who needs X" is s-expressions. At least then you are left with something that composes a little bit.
I’ve never seen Smalltalk before, but I did find the verbose syntax of ObjC had some benefits.
That being said, typical C programmers don’t add all that whitespace, so the “who needs dots” and stuff is a bit misleading.
account deposit: 100 dollars.
account/deposit $100
That's why it isn't more popular. In some ways it was a few years too early (to hit the zeitgeist around DSLs), but it was also a few years too late for its proprietary model.
Rebol died (for all intents and purposes) because it stayed proprietary without a large enough proprietary market too long, and good enough open source languages took the niches it could have had and built out robust ecosystems that it never developed.
Red has been disadvantaged by the ecosystem consideration, and hasn't found a killer focus that gets people over that in enough mass. They tried chasing crypto for that...
The development pace of many of the new languages is relatively slow, despite having some great ideas, syntax, or features. Which means years before they have a large enough ecosystem and libraries, to even come near to mounting a challenge to the more established languages.
For instance, another new one out there that I like is VLang (https://github.com/vlang/v). Like Red, it needs to find a sweet spot that will propel it to greater usage and recognition. Partly that can be cross-compiling and cross-platform application development. Also, strong emphasis on mobile development for both Android and iOS would help, but Apple makes their part of it difficult. To stand out, it means having easy to create UIs, their own IDEs (to maximize language features), updated documentation (to help beginners), books about it, etc... Just being on Visual Studio Code, with a hundred other languages, makes it hard to get noticed.
Compare Red with established heavyweights like C#, Python, JavaScript, or even contenders like Delphi/Object Pascal. Not so easy to pull attention away from those languages and the thousands of projects using them, unless something very compelling can be shown or proven.
The last stable release has been stuck at 0.6.4 since 2018. I know the lead developers have recent automated builds (December 2021), but come on, such is not going to inspire faith in casuals to join the bandwagon nor keep getting mentioned by the media. Many users like to see newer stable releases, until the project achieves its stated goals. A lot is to be said for maintaining momentum and enthusiasm.
That's another aspect of the hurdles for the newer programming languages, it's harder than ever to keep people's attention and whip up excitement.
Something to point out, is there is a lot of old tutorials and information on Rebol that becomes more useful as references, if a person learns any of the descendant languages.
Red (https://www.red-lang.org), is a very good open source offshoot. If a person is choosing between them, I think most would recommend it. But, the problem with Red is its development can be described as sluggish. The lead developers appear overly preoccupied with other projects, as oppose to getting Red into a more useful state and delivering on the stated goals and expected features.
For example, one of its main benefits is easy cross-compiling to other OSes. However, it's stuck in 32-bit, and needs to have a 64-bit version to keep pace with the requirements of macOS, iOS, and Android.
If Red's development was to keep on pace, which is important for multi-OS usability, I do think it would be worth knowing. Quite powerful and easy to learn language, for potentially a wide variety of purposes, with a light footprint.
julia's parser (which is written in scheme!): https://github.com/JuliaLang/julia/blob/master/src/julia-par...
Well, money! is a datatype, $ is a sigil that identifies a money! literal.
But therein lies the problem. Let's forget about programming for a moment and talk human languages instead.
In english, you say "Cheese omelet". In dutch, you say "Kaas omelet". In french you say "Omelette du fromage".
Neither is better than the other; it's just how it is. A native english speaker who is learning both dutch and french may posit the feeling that dutch feels 'more natural' and has 'more obvious word order'. But I'm sure you'd agree that this is just based on happenstance; simply because english and dutch so happen to match. There's nothing intrinsically better about putting the cheese in front of the omelet instead of after it. Nevertheless, for a native english speaker, dutch will seem simpler... __right up until the moment you turn "native", and you no longer translate each word on its own back to english first__. Once you've hit that level, there's no difference. At all. You hear the words and your brain visualizes a cheese omelet instantaneously.
The same logic applies to programming langauges. "It reads like a sentence"? What are you on about? If I see this code:
account.deposit(Dollar.of(100));
Rails in particular is egregiously in violation of this ridiculous aim to make it look like english (but, fortunately, nothing so crazy as AppleScript). Rails prides itself on being able to write `5.minutes` - they monkey patch numbers to add a minutes function.
But in programmese, of any flavour, that makes very little sense. You want to create a value of type Minutes, or in some languages, you want to create a value by using a function from the namespace Minutes, and this operation that requires a parameter (the amount of minutes). Putting the param _before_ the namespace / class / type / function name / whatever your programming language uses here - is _highly exotic_ - something very very very few programming languages do. Except Rails (I'm going by memory here - I believe the minutes function on numeric types is a monkeypatch Rails adds, it's not stock Ruby). They do it, apparently (in that they call it out in their tutorials) because "5 minutes" reads like english and leave it at that - clearly insinuating that 'reads like english' is upside.
No it isn't.
And that's why "account deposit: 100 dollars." is by no means "easier to read" simply because it reads like an english sentence.
account.deposit(Dollar.of(100))
As an aside, I always find it funny when people use "monkey patching" in an attempt to decry giving language users expressive power. I love monkeys! I love monkey patching!
I can’t speak for this particular Rails usage, but one of the most powerful things you can do with Ruby is build domain-specific languages without modifying the language itself. *This is a core feature of Ruby.*
The criticism you’re making is one of the Rails DSL — there’s nothing in Ruby preventing you from instead writing account.desposit(Dollar.of(100)).
Put another way: This is like people criticizing RISC-V for not having multiplication in the core ISA — they don’t seem to grasp that RISC-V is an ISA construction set. Ruby is a language construction set.
Whatever context the term may have originated with, it far outgrew those origins. I definitely don't instinctively think of python programmers snubbing ruby when I hear the term.
That can be done in strongly, statically typed languages with either extension functions (Kotlin, Dart) or type classes (Rust, Haskell).
People do it because there are advantages beyond the subjective reason that it reads better (I can speak several human languages and in all of them you would say number-timeUnit - so it's not just English even if it's not completely universal). It's also easier to "look up" functions based on the type of the value, for example.
> [<Measure>] type km;
> [<Measure>] type hour;
> let distance = 60.0<km>;
> let time = 0.5<hour>;
> let avgSpeed = distance / time ;;
val avgSpeed : float<km/hour> = 100.0
What I want to see: 5 + 3
What I don't want to see: Add the number five to the number three.
No you don't, that's literally "Omelet of the cheese". You say "Omelette au fromage", which is "Omelet with cheese".
I do agree with your broader point, though.
In languages like Nim with Uniform Function Call Syntax this is actually completely natural and universal: f(a, b) and a.f(b) are completely equivalent in all cases. So if you have an ordinary `minutes` function that takes a number and returns a time/duration, you can write either 5.minutes or minutes(5) as the fancy takes you. No special monkeypatching required, it just works everywhere for every function and every type.
Exactly. This is why I dislike SQL. The relational model is great, but it was hamstrung at birth by the foolish insistence that it "read like English" so that non-programmers could write queries. Now we're stuck with a deranged syntactic mishmash.
That's not what we want in a software language.
In fact, we should not even call them 'languages'.
If by accident of history we called it 'Machine Instructions' - would anyone have ever tried to make it seem like Enligsh?
Clear, concise, unambiguous is I think what we want. Just enough overhead to keep it clear but not so little that it's ambiguous.
"Deposit 100 dollars in my account." is a sentence, and that's doable in most languages. It just depends on how high you want to go with it. Functions are ubiquitous and powerful:
deposit($(100), in(my_account))
deposit $ 100, in my_account
deposit($(100), in(the_river))
hey OBJECT !, I want you to ACTION with ARGUMENTS
so ... "hey account!, I want you to make a deposit with $100"
account deposit: $100
bankTeller deposit: (100 dollars) in: myAccount. account acceptDeposit: 100 dollars.
Or, for a more realistic domain model:
ledger credit: accountNumber debit: cashHoldingsAccount amount: 100 dollars.You can see the opposite end of that spectrum in Go, which can be readily read by anyone since there's generally only one good way to do anything.
I don't program in Ruby but every time I look at it I see something different depending on who wrote the code and what their personal style is
Python and Ruby occupy similar niches. Python has many more libraries, so people will say, that's why Python has been more successful, but IMO, even if Python and Ruby had as many useful libraries, most people would still choose Python, because it's a simpler and easier to learn language. That may have contributed to Python getting a headstart in the beginning.
I'm sure some people would say that's a case of "worse is better", but I think you also have to have some empathy for other programmers. When collaborating on a programming project, having a project that is easier for others to understand is easier. Having a language with less weirdness, less peculiarities and less complexity is a plus.
Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.
My inkling is that this is because it is hard to have a general purpose language that lends itself to both novices and experts, and to small scale and large scale. Not impossible, but hard. Those categories desire/need different things, and will use the language in vastly different ways.
BASIC (for all its problems) was a better first language for many people than C or Fortran, but BASIC also didn't scale well to larger systems (structured variants scaling better). Then you start getting BASICs supporting OO and other features which complicate them and lose the appeal to novices, but more effectively meet the needs of intermediate-to-advanced users and maintainers of medium-to-large scale systems.
See also Pascal and its evolution. From a small language to a still small but not as small language in Delphi and others. For the novices, they can still use that small core. But it's now harder for them to onboard with a larger project or a project developed by more advanced users of the language. Especially as the standard library (for the language implementation, if not the language proper) grows.
Scheme, over the various revisions, has seen a similar conflict, culminating in the effective rejection of R6RS and the division into small and large for R7RS.
And those are languages that were largely meant to support novices and learners. Python started off similarly. Now it's older, and its users have aged, and they want to do more powerful things with it and maintain larger and larger systems with it.
On the small vs large side, look at the evolution of JavaScript. It was literally meant for in-page scripting, to do small things and not be the larger system, but a mere component. Like a shell script that copies two files contrasted with the actual OS or shell implementation. But now 25 years or so later it's a vastly different language, and people are building distributed systems on top of it.
Python is the same way, there is still (and always has been) a core that is particularly well-suited for novices and a slightly larger core that is sufficient for any small-to-medium system. But as you gain expertise and want to use the language to do other things, or to develop larger systems, you will likely exceed that core. Delphi with Object Pascal was similar. You could still use that core, and accomplish a lot (same with Python), but you cannot guarantee experts or larger systems won't exceed that core.
And that's the language dilemma: How to appeal to both novices and experts, small and large system maintainers? The features that each will want or need are different. Go stayed pretty stable for a decade and kept to its mostly small core, but even it has added generics now because people (maintaining larger libraries, in particular) are chafing under its present constraints. And with these changes, you'll see a (potential, may not happen I suppose but I'd be surprised) major shift in the way the language is used by more expert users that pull it away from its previous model.
You're probably right about the availability of documentation, but I also think Python is much easier to generally understand at a glance. Less features, less quirks means the language is easier to learn.
this has been true for a while, the 'zen of python' was lost a long time ago.
i think this is partially because of how much commercial popularity it has, and all the different types of things people need to do with python.
I loved pascal syntax.
IMO Pascal actually has much better pointer syntax than C, even with the caret (which is basically a pointer/arrow up without the tail):
1. Pointer de-referencing is done via something that looks like a pointer and doesn't reuse some math operator (despite writing C for more than two decades i still pause for a bit whenever i want to multiply a pointer to a number)
2. Getting the address of something is via the "at" character @ (which kinda makes sense as a pointer to something is a way to refer "at" it), no way to mix the two
3. No special syntax for referencing a member of a record (struct) through a pointer, all record members are referenced using a dot ".", all pointers are de-referenced through the caret "^" so of course all members to a record pointer is done through using both of them: "^."
Also i think that the reason C has -> is because in C pointer de-reference is a prefix whereas in Pascal is a suffix so without it you'd either have to write (*ptr).foo. Pascal avoids that by having both be suffix operators.
In the case of Smalltalk, it was Digitalk's "Methods" (the precursor of Smalltalk/V) that adopted := for assignment in place of the left arrow (though the IBM PC character set actually had one, just not with the same code as ASCII 1963) since all of its tutorials were aimed at Pascal programmers.
That distinction comes from early C (pre-ANSI / K & R C), where structures were really definitions of offsets (and said offsets were global, you couldn't have different 'offsets' for a member with the same name in different structs).
Say you had a struct 'struct mystruct {int a;int b;int c};':
You could do '200.b' to access the value at the 'b' offset of the memory location '200' ( '*(int*)( 200 + offsetof(struct mystruct,b) )' or '((struct mystruct*)200)->b' )
And '200->b' would access offset 'b' of the memory pointed to by memory location '200' ( '*(int*)( *(intptr_t*)200 + offsetof(struct mystruct,b) )' or '(*(struct mystruct**)200)->b' )
I remember learning Pascal and C around the same time coming from BASIC and assembly and Pascal didn't seem particularly easier only more verbose. New concepts like types and pointers were much more of a hurdle than syntax.
Function: something that may have side effects but that also returns a value.
Pure Function: something that only returns a value, and has no side effects.
That's how I always understood the terms.
I guess you forgot about the semicolons which must or must not be there depending on location. And the final dot.
And, if we move a bit away from pure syntax, strings, even modern ones, which start at 1 for backward compatibility reasons with the original very limited Pascal strings, while dynamic array start at 0 (and original limited pascal arrays start wherever you like).
The final dot is clarifying the end of the program or unit. It also makes a more clear distinction between the main body or subroutine of the program versus other functions and procedures that are only component parts.
I don't think people are saying that Pascal is a perfect language, as none are, but rather it's an easier to understand and read language. Many teachers would agree with that assessment.
Especially in the 70s and 80s, that was a huge performance barrier.
Contrast this with C, which probably won because of its largest benefactor, Bell Labs and UNIX. Smalltalk in some sense was a competitor with UNIX itself.
Smalltalk's influence is everywhere, but the sad thing about it is that it's dev tools were so much ahead of time of anything else.
As a Python coder, I played with Pharo and tried several tutorials and read a book on Smalltalk-80. I get the gist of things, but have trouble actually writing the code as things aren't obvious and there is no StackOverflow or cookbook for common tasks. It took me forever to figure out how to do file IO and that sort of thing. The other problem is that deployment isn't just running a script, but deploying the image and runtime of some obscure language nobody has ever heard of in enterprise software and no IT department is going to be cool with it.
i actually meant pharo above, i never used genuine smalltalk, just what the pharo mooc gave us
https://www.cincomsmalltalk.com/main/successes/financial-ser...
Of course, mission critical business software still needs to be deployed long after fashions change.
It is a shame that Self and F-Script didn't gain a bit of attention.
F-Script was really awesome, even more with F-Script Anywhere
StrongTalk was also very influential, because many of its developers also ended up working on core parts of the JVM and V8 JITs both at Sun and Google.
A huge reason why C syntax is "not weird" is because its weirdness has been normalized. I didn't realize how absolutely bizarre some of the things in it were until I was an undergraduate teaching assistant for a C programming class for Math and Engineering majors.
The big problems I remember:
- Why {} braces?
- Why A = B? They're not actually equal. This can be a huge conceptual stumbling block.
- Why is this function returning "void"? This makes no sense, that's not a function.
- Why A.B()? Period gets read as a sentence terminator and that function is being called with no parameters, which makes no sense.
- Why do we use square brackets [] and not parentheses () for arrays?
- Why do we need a ';' at the end?
- Lots of confusion over `&&` and `||`.
- Problems understanding `+=` and similar.
Old Smalltalk editors did some things to make the language more understandable, such as turning `:=` into an leftward pointing arrow and `^` into an upward arrow. Once I saw this in practice, it made a lot more sense to me. Not that Ruby and Rust both have the `|vars|` syntax.
Pascal-family languages like Ada look "too weird" because most people learned a C family language early on. It'd be like saying Russian or Japanese is a weird language because you only know Romance languages.
Personally the distinction between subroutines and functions always struck me as overly math-centric thinking, because it's not an interesting difference as soon as non-local state exists, which is almost always the case.
> - =, +=
I don't quite get why this remains contentious; even in math these are somewhat overloaded ("=" in equations vs. "<=>"/"=" for equality of equations, for example); code simply is not math. Why would the symbols mean exactly the same thing in a different context?
> - Why {} braces?
Big braces have always been used to group stuff together (e.g. case distinctions, summaries etc.), so it kinda makes sense to use that for groups of lines, i.e. code blocks.
> - Why do we need a ';' at the end?
C/UNIX was originally written using actual teletypes, so not only does ";" make it easier to parse, but it also gives you a very explicit marker that you definitely reached the end of the statement. That matters when every line you're looking at when interactively editing a file uses up some paper.
It's related to the same problem with = as assignment, note GP's context: Math and engineering majors. They have been taught, assuming they paid attention, that = is not an assignment but a relational statement. If they've never programmed before, having = as a thing that changes the system state is still new to them. This is a common issue I've seen in tutoring over the years, where students' mental model is closer to Excel than to <standard programming languages>. That is, if you do this:
a = 10; b = 20;
c = 3*a+c;
printf("%d\n", c); // prints 50
a = 20; // this demonstrates part of their confusion, they half-get that it is an assignment
printf("%d\n", c); // prints 50 ?!?!?
> Why would the symbols mean exactly the same thing in a different context?
When you have one mental model that you've been taught for 12+ years and are 18-20 years old and don't have a ton of experience, this is confusing. That it is not or was not confusing to you is either because you had a learning experience that specifically targeted this confusion, you made the connection more readily (maybe closer to the top of your class than average), or are looking back on your past and neglecting how far you've come since you were that age and had that level of understanding.
The problem with += (IME) is with the incomplete and incorrect model that students have, += is one of the situations that can force a realization that = in C-syntax languages is assignment and is not a relational expression. But if they haven't grokked that yet, it's jarring.
To make this a slightly more useful comment, I'll mention that I confirmed that even with -Wall neither clang-6.0 nor gcc-9 gives a warning about the second assignment to "a" being unused. This would often be a nice thing.
Not really, many programming languages generally considered math-centric are perfectly fine with functions returning (or taking) a unit type of some sort, category theory (and even its predecessor abstract algebra) has a lot of use for initial and terminal objects, etc.
It’s more like mathematicians used to be vaguely uncomfortable with non-referentially transparent things when computation as a mathematical object was new. They realized the error of their ways pretty quickly, all in all, but a realization such as this can take decades to make its way through layers of educational materials.
> I don't quite get why [ = for equality] remains contentious
Because it’s a huge problem when teaching, even if it isn’t for competent practitioners. Maybe it wouldn’t be if we put CS (and graphs, and games, and lots of other things utterly lacking in prerequisites) in elementary-school mathematics where it belongs, but if wishes were horses I’d have a racing franchise by now.
I mentioned the = thing because I only ever see this brought up by what seems like a very particular developer tribe. I used to tutor 1st semester CS students in programming C and Java - for many this was the first time they were programming - and I don't think I've ever seen someone confused about it. Lots of other things though; programming is hard.
Well, the word is taken from math, it seems pretty rude to take a word while preserving nothing of its original meaning. A function is a mapping between sets, it has nothing to do with abstraction or reusability or any of the dozen other keywords said when introducing the concept in programming courses, it's just an association between sets satisfying certain (relaxable) constraints.
From this perspective, a function that returns nothing is a hilarity, it collapses all elements of its domain to a single point. A function that takes nothing and returns nothing is a deviancy, where is the mapping then if nothing is taken and nothing is returned?
Keep in mind that the usage of 'functions' to denote callables* is a new thing that happened probably around the mid to late 1980s. Computer Science always called self-contained pieces of code '(sub) procedures' or '(sub)routines' or '(sub)programs'. Fortran, the oldest programming language, honors the difference until now. Pick any conference paper or book written before 1980 and I guarantee you that 'function' will denote a literal mathematical function used to describe some property of an algorithm or declare a certain constraint on a computational object, and that callable code blocks are always called one of the terms above or their variations.
>because it's not an interesting difference as soon as non-local state exists, which is almost always the case.
The thing is, there is no such thing as 'state' with functions in the first place. The word denotes something in a world that knows nothing about change or time, taking the word and redefining it to include those concepts is meaningless. Imagine if I took numbers, added physical units to them, then insisted that this is the mathematical definition of numbers all along. That's what happened with functions.
Also how exactly is the difference between pure subroutines and mutating subroutines irrelevant when non-local state is involved? it's the exact opposite, the difference is an irrelevant and opaque implementation detail if the mutated state is callee-local and never leaks to the caller, otherwise it's an outsized obsession of life that can mean the difference between a good weekend and a sleepless 24 hour and all things in between. It's exactly when it's non-local that mutable state is revealed as the horsemen of death it is.
* : see? even the verbs don't make sense: how exactly do you 'call' an association? it's a mapping, you either 'apply' it or 'refer' to it or 'look up' an element in a table listing (a sample of) its input-output pairings. Similarly, you don't 'return' from a function, you never 'went' anywhere to return, you had an element and used it to get another element with the help of a mapping between the 2 sets containing the 2 elements, this 'happened' instantaneously, timelessly, there is no instruction pointer in math breathing down your neck and telling you to return here and go there.
It's about command/query separation which is still a best practive to this day.
To give another PoV: I've taught javascript to absolute beginners (graphics design students coming from humanities studies with pretty-much zero programming or general "scientific" ability) and the syntax, fairly close from C, was very much not an issue for them, unlike the maths required ; I had to spend much more time explaining how transformations in a 2D plane, vectors, etc... do work, than correcting syntax mistakes.
In ~20 hours of class they were pretty much all able to write small programs with for-loops, conditions, etc. which did nice visual effects in p5.js so I'd say that teaching the basics of programming is an entirely solved problem in 2021 ; whatever the topic, you cannot expect to teach stuff faster to a whole classroom.
What C syntax is this referring to?
struct a {
void (*B)();
}
struct a A = { .B = ... };
A.B();What I should have written:
- Why is "Foo()" a function is being called with no parameters, which makes no sense.
- What is "A.B" Period gets read as a sentence terminator. I learned C++ and Java very early on in life and had never considered A.B to be an issue.
As for Smalltalk I can say that it's the only language that has never clicked with me. I have tried the usual languages including Lisp and some weird ones like Forth, Factor and the APL family and never had an issue with those but with Smalltalk I can't go beyond writing factorial. Actually if you sat me in front of a Smalltalk environment it would take me ages to figure out again where to click in order to even have the chance to create such method. The biggest problem with Smalltalk is that you have to give up your tools in exchange of some alien technology that isn't really that good to begin with.
Disclaimer: I have tried Pharo, Squeak and some commercial offerings such as Cincom.
Also I think most super popular languages have a niche. Whether its webapps, text processing, low level, etc. Smalltalk lived in its own world and it was hard to integrate with the OS and other capabilities of the system, (try writing a wrapper for like OpenGL or other libraries for example) and I think that somewhat prevented it from finding a great niche to thrive in.
Often those who learned C family languages first (C, C++, C#, Java, JavaScript...), can feel there is "something wrong" when viewing the syntax and structures of other languages. When everybody only wears dark blue or black, somebody wearing purple or beige could be considered "weird".
The creator of Ruby, Matsumoto, was a C++ programmer. It appears his intention was to make the language a bit more verbose, as is Pascal and BASIC, to increase ease of use and readability more than exists in C++. A person who used Ruby, would probably find reading and adjusting to Pascal or Lua much easier to do.
Smalltalk gets a bit "weird", because of how they do OO. The structure and syntax used reflects a different way of thinking. Saying that Smalltalk "died", seems to be part of this odd labeling for any language not in the top 10. Are Rust, Kotlin, or Go dead because they never were nor are in the top 10? Smalltalk was never that tremendously popular to begin with, but it certainly didn't die. Go check out Pharo (https://pharo.org/).
You're just knee-jerk reacting to a different syntax.
(You might not like the "image" approach, but that's orthogonal - and not even necessary of all Smalltalks. But you should have absolutely no problem reading and understanding the language's syntax).
I much prefer more modern languages that allow you to explicitly name the parameters when you need to, but other than that, never requires it (e.g. Kotlin and Swift).
For instance, seeing "public static void" all over the place in java is irritating.
On the other hand, if I'm doing a code review and I can't do a quick "jump to definition", I'm much happier reading code like:
t rotateAround: v by: 90 degrees toRadian.
t.rotate(v, 3.14/2)
Yes, Java is excessively verbose. No disagreement there. But so is Smalltalk.
Your argument is basically whataboutism.
My point is that Kotlin and Swift both solve Smalltalk's mistakes elegantly by making the parameter name optional. Use it if you have to, but omit it otherwise. And as it turns out, most of the time, you don't need to mention the name at all.
Explicit? Sure.
But verbose?
There's no good reason for that, except that when Smalltalk was designed, we thought it was a good idea.
We know better today.
What if you are a "sometimes" programmer -- you write some code, then come back to it months later. In many ways this was the intent behind the development of early personal computing. Verbosity is an advantage in these cases because in theory it becomes easier to discern what is going on without having to be immersed in the language, frameworks, and environment all the time.
Keep the verbosity to a minimum while making the code easier to read, understand, and maintain.
There is not an objective universal boundary between explicit and verbose. Some readers will need more, some can guess correctly with less.
Usual method in Smalltalk, including its definition, is shorther than this sentence.
Do you mean in base Pharo, or do you mean in an enterprisey system built using Pharo?
> As a reader, you should be able to tell that “a” is sent message “negative” (no parameters) which comes back true or false; “b” is sent message “between: c and: d” which also returns true or false. The results are ORed together to become the receiver for the “ifTrue: [a := c negated]” message.
When messages are sent to boolean values, the language is harder to read.
Earlier in that into we were told that the first argument's preposition is always fused with the name of the method/message/operation, while subsequent prepositions aren't thus fused. That also makes the language hard to read.
We are given examples of methods/functions which are adjectives, e.g. "negated", while others are verbs in the imperative voice, e.g. "make", "rotate" etc. That also makes the language (or its idiomatic use) harder to read.
A few thoughts.
For better or worse (worse in the final analysis I guess), Smalltalk doubled down on an odd proposition. Instead of tools and compilers and language syntax/model being orthogonal/independent things, what could be leveraged if they were highly coupled? If you read the Byte article, and some of the other seminal Smalltalk papers you see this theme.
Smalltalk syntax really struggles outside of a Smalltalk environment. I tried GNU/Smalltalk and a couple of other “IDE-less” Smalltalk in VIM. I’m very comfortable worth VIM. It just didn’t scale well.
But it was a dream in a well done IDE. For the last 10 years, I do C(++), Elixir, Kotlin, Python, Swift/ObjC in a variety of VIM, PyCharm, VSCode, XCode, AndroidStudio, Eclipse, and QT Creator. The IDEs just don’t go as far at all here. The text editors are more modern, but the ability to work with (navigate, refactor) the code at a high level is nothing compared to what it was in some of the better Smalltalk IDEs. To date, no refactoring engine has approached the level that John Brant and Don Roberts did for the original refactoring browser. Unit Test integration at the code browser level existed before the other NUnits were even built. The Smalltalk debuggers were so cool. Interactive process/context inspector/manipulators would have been a better term.
I’ve theorized that the reason Smalltalk the language and Smalltalk the syntax could marry well is that they found a sweet spot in language complexity that made the IDE easy ish to implement and manipulate code, at a syntax level and at a code structs level. Smalltalk syntax existed really only at the method level. Smalltalk code structure was modeled in the “image” as a code database more than as a textual flattening.
It’s interesting how a paper dated 2000 might give the impression that some archeological find reveals while Smalltalk was not a success. I think that would be a misnomer. I was there. This sentiment was pretty common. “It’s too different” is a pretty timeless trope. All this paper shows, is that just like today, there is a small subset of computing enthusiasts that get excited about new/cool/different things, while the populist/conservative types push for things to mostly stay the same.
Smalltalk required a paradigm shift to appreciate. Most of us have limited resources. We don’t have time to explore every revolutionary paradigm shift; the ingress process is just too high.
I’m not trying to pitch Smalltalk paradigm shift as a worthwhile payment for what you got out of it. Those of us that paid the price to achieve the shift, appreciated what the difference was about, even if we’ve mostly moved on since then. Papers like this were a common “I don’t think the shift will be worth it” sentiment.
I put that idea forward because I’ve seen people working with the Emacs/Common Lisp combo wishing for something like that… that it was Lisp all the way down like an old Lisp machine. Seems like some are looking towards GNU Guix to approximate that sort of system.
For what it’s worth, I’m prepping myself to spend the next couple years at least exploring interactive programming systems like these, so perspectives like yours are fascinating to me. I’m not looking for a programming job any time soon (or maybe at all), so I’ve got time to study most seem to think is “alien technology.”
Can you give some examples of the refactoring operations that are unique to that browser and not available in other IDEs (for other languages)?
Some of the other one's I remember involved parameter add/removal (I think PyCharm can do this one?), extract to component, and high end ways to manipulate the class tree like add/remove/pivot class hierarchies.
There were some fun "extras" too like convert to/from ValueHolder (a ValueHolder is a Pointer with Notifications attached to it).
Where the magic began though was in this very simplicity all-in-one thing. To mess with the Refactoring engine in IntelliJs tools or VSCode, I have to learn another language, do another build environment. In Smalltalk, you were there already. It's all in the same code browser. Just scroll down to that part of the system. The AST is so simple, it's expressed in ~15 Node Types (compare to Ruby which has +90 parse node types someone told me?). The matching node type was a single additional node type. So you could see the code that did the refactorings. And you could use the same match trees they did. So you were minutes away from deriving your own refactorings. The first few times, it took longer than just doing them by hand, and then you got good at it and could do some cool things.
The only newer language that I've seen that maybe has this same "because we kept it simple we can do cool things" ethos to date for me is Elixir. My guess is there some others. My guess, is that like Smalltalk, any of these "mind blowing/changing" language/systems have a small but passionate following, but are not enjoying viral adoption.
https://www.jetbrains.com/help/idea/structural-search-and-re...
If I had more time I would point out the scientific papers and mailing list/forum/blog posts where there has been fact supported arguments why Smalltalk is better readable and writable than almost any other programming language. Arguments like [1] the syntax is really short and simple [2] or it was developed with children in mind [3][12].
But the OP should recognise that there are (many) cognitive biases at play in his affection or aversion to this or that programming languages just so it confirms to his existing beliefs. And his existing beliefs where formed similar to how the concept of 'mother' is formed in ducks, by imprinting at birth [5]. If he had started out with another programming language, than that would be the language he would defend in a blog post. Its like he is defending qwerty keyboards as being the best keyboard layout instead of the historical inertia and cognitive bias it is [11].
Alan Kay and Dan Ingalls who invented Smalltalk and its syntax in research at PARC redesigned Smalltalk several times to improve it, including its readability while testing it out on thousands of users including children. As good science this has been documented very thoroughly but I lack the time right now to point you to these hundreds of references. Maybe HN software allows me to add these later.....
Maybe OP could design us a programming language (with Ometa [7]) that would be better readably and writable, instead of just voicing his tribal preferences and allegiances?
For those who want to play and code with all the versions of the Smalltalk language since 1972 I can recommend [7] or [9] if they don't want to install it first. Better still, download the best app (and original) Smalltalk at squeak.org [10]. Don't forget to look into Self [13][8]. Squeak Smalltalk is also a VM that has been ported to more operating systems and environments than any other language I know of, even Linux. Due to memory size limits, its hard to put it on systems with less than 1 MB memory, but not impossible. I'm hoping to release a version for tiny microcontrollers with less than 100KB memory someday.
[1] https://wiki.c2.com/?SmalltalkSyntax
[2] https://squeak.org/documentation/terse_guide/
[3] https://www.researchgate.net/publication/221501755_The_Early...
[4] https://www.teachthought.com/critical-thinking/cognitive-bia...
[5] https://cerebromente.org.br/n14/experimento/lorenz/index-lor...
[6] https://www.researchgate.net/publication/220828937_OMeta_An_...
[7] https://smalltalkzoo.thechm.org/
[10] https://squeak.org/
[11] Recent talks on youtube by Alan Kay
[12] https://smalltalkzoo.thechm.org/papers/EvolutionOfSmalltalk....
[13] https://ourself.io