16 ms·

I can read C++ and Java but I can’t read Smalltalk (2000) [pdf]

110 points by tjalfi 5y ago

phendrenad2 5y ago
Probably part of why Smalltalk died. The C syntax and the BASIC syntax became ubiquitous, and things like Pascal and Smalltalk were just too weird. Luckily we have Ruby, which is almost-Smalltalk with a BASIC-like syntax.
- mseepgood 5y ago
  Compared to C, Pascal has the less weird syntax.
- VWWHFSfQ 5y ago
  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. It seems like it has every syntax in there somewhere.
  - api 5y ago
    That's a problem with LISP-style languages too. Too much flexibility and dynamic syntax leads to write-only languages, or at least languages that are write-only-by-the-original-author. 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.
  - ferdowsi 5y ago
    The only way I've seen Ruby work professionally is by using tooling that prevents developers from getting too clever with creating write-only code.
  - nauticacom 5y ago
    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 I'd say this is a plus, at least in certain dimensions. One of the best descriptions I've heard of Rails' ActiveSupport (a collection of extensions to built-in types included in Rails) is as a dialect of Ruby, one specific for developing web applications. Other domains could and should use different dialects.
  - snek_case 5y ago
    IMO that's one of the biggest weaknesses of Ruby. The language offers lots of different ways to do the same thing. You can say that makes the language more expressive. Sure, but it also means as a newcomer, there's a lot more language features to learn about. It makes the language less approachable to outsiders. 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.
    - setpatchaddress 5y ago
      I think it’s much simpler than that. Ruby didn’t have good documentation in English until the mid-2000’s. Python was in use by the English-speaking world before the turn of the century. Documentation + you can generally understand it at a glance == total Python dominance. Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.
      - Jtsummers 5y ago
        > 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.
- jacquesm 5y ago
  Pascal is actually one of the few languages that is quite readable, even for novices to programming. That's no coincidence, it was designed that way.
  - froh 5y ago
    Yes the only "weird" thing in pascal was pointers and pointer dereferencing with the caret ^ I loved pascal syntax.
    - jacquesm 5y ago
      Yes, C got that bit right. -> made a lot more sense.
      - pyjarrett 5y ago
        In Ada (Pascal derivative), there's implicit dereference so we just use it like normal, `A.B`.
        renox 5y ago
        Which has pros and cons: a pointer indirection can be expensive so the potential additional cost is hidden and pointers semantic is so different than hiding their usage is a bit risky.. That said this simplify refactoring and is much less 'noisy' to read. My preference is Pascal style but with an @ instead of a ^ which feels a bit weird.
    - badsectoracula 5y ago
      The caret is because ↑ (arrow up, in case HN drops it) wasn't really "typeable" (or even available) in most computers. I'm not sure if Wirth's Pascal even had the caret - i do have an old book about Pascal which uses the arrow for pointers, but i remember seeing the caret in various dialects. 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.
- fault1 5y ago
  I think Smalltalk's demise was really from the fact that it was a entire environment that had to live in a virtual machine. 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.
  - agumonkey 5y ago
    I think none of the reason applies but it's tongue in cheek.. I think it all points at cultural maturity. Same smalltalk today might be well received because machines are wide and fast and people have seen more languages. It's surely easier to show ST to py or js coder today now they've seen large syntax changes and paradigms (FP, async etc)
    - 7thaccount 5y ago
      Pharo is a Smalltalk, but they're ok with moving in new directions. 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.
      - igouy 5y ago
        Maybe IT already deployed https://www.cincomsmalltalk.com/main/successes/financial-services/jpmorgan/ https://www.cincomsmalltalk.com/main/successes/financial-ser...
        7thaccount 5y ago
        I think most users of Cincom Smalltalk (and other esoteric language users such as Volvo using Dyalog APL) occurs most often due to historical reasons. Please note that I don't think poorly of these languages and would use them over something like Java in my own pet projects any day.
- pyjarrett 5y ago
  > Pascal and Smalltalk were just too weird 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.
  - formerly_proven 5y ago
    > - Why is this function returning "void"? This makes no sense, that's not a function. 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.
- TurboHaskal 5y ago
  I believe it was mostly economical circumstances just like the other poster said. People put up with everything as long as there is a market and they are getting paid. 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.
- overgard 5y ago
  I doubt it. C++ syntax is all of: bizarre, hideous, and ambiguous and yet it never limited C++ because at the end of the day C++ was extremely practical. Smalltalk didn't take off (Im not going to say died because it's not dead) because the development tools were expensive and the runtime was frequently not fast enough and you needed a very powerful for its time computer to use it. 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.
- Tozen 5y ago
  I also disagree with your assessment. Pascal has greater readability in comparison to C, so it's "weirdness" is in the sense that it's more verbose. Arguably, the inherent problem of C family languages is their terseness tends to make them more cryptic and symbolic. But because of their popularity, many have become used to the eccentricities. 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/ https://pharo.org/).
jayp1418 5y ago
I am not a programmer but can read Ada Language :D
- agumonkey 5y ago
  kudos you're an embedded problem solver
- zerr 5y ago
  When reading code, skimming is more important actually. C-like syntax (symbols instead of prose) makes skimming easy.
xkriva11 5y ago
Let me add a classic "tutorial": 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
- Jtsummers 5y ago
  That's literally from page 2 of this, you could at least state that you're quoting the document. Also, you missed a step. Before "ambiguity": t rotate by a around v; //Who needs commas?
- alfu 5y ago
  Why not compare it with t.rotate(rotateBy, around)? Could a,v used for many purposes and this example allows us to indicate their role for this specific call?
  - Jtsummers 5y ago
    Because a and v would be more typical variable names than rotateBy and around. Note that the author did not change the variable names in the translation process, they left them alone. So you could drop any variable in there but the calling of rotate becomes clearer (subjective) by switching to keywords and no longer relies on programmer discipline to have good variable names. 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.
  - msbarnett 5y ago
    Because those are names the caller decided upon, so they can just as easily misinform the reader as correctly educate them. The caller could have mistyped the call as t.rotate(around, rotateBy) and the error in the effect might seem very mysterious indeed. The beauty of keyword args is that the mapping of caller's name to function argument name is explicit, and therefore reads correctly or incorrectly immediately at the callsite t rotateBy: point around:degrees is obviously an error, without sending the reader to look up the definition. Compiler-enforced clarity rather than relying on every individual piece of client code to always name things well & never make a mistake.
nauticacom 5y ago
Snippets like this: account deposit: 100 dollars. are why I love Smalltalk (and its followers, e.g. Ruby). So much expressiveness, reading like a sentence. And Smalltalk even had the ingenuity to use period as a statement terminator, so it feels even more like a descriptive sentence describing the domain concept.
- nmz 5y ago
  Rebol takes things further by identifying $ as a datatype. account/deposit $100 Nobody cares about rebol but I always bring it up in terms of expressivity.
  - dragonwriter 5y ago
    > Rebol takes things further by identifying $ as a datatype. Well, money! is a datatype, $ is a sigil that identifies a money! literal.
  - nauticacom 5y ago
    Just took a quick look at Rebol and it looks interesting! I love languages that push the boundary of what they allow programs to "naturally" express
  - carapace 5y ago
    Yeah, I have no idea why Rebol and Red aren't more popular. ( https://www.red-lang.org/ https://www.red-lang.org/ ) They pack such a bang for the buck it's almost embarrassing for other language/runtimes.
    - Jtsummers 5y ago
      Rebol itself is practically dead, no new release in a decade. It was also proprietary early on and a "weird" language (interesting, and good, but non-standard in so many ways that it was very niche). That killed its potential in the late 90s and early 00s when everyone was moving to open source scripting languages that filled the same niche, but with more conventional syntaxes and free access. 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.
rubyist5eva 5y ago
I can read Ruby and Smalltalk but C++ is like ancient hieroglyphics that require a PhD in classical studies or something.
nick__m 5y ago
I had the same problem in graduate school until I realized that Smalltalk is not designed to be read outside it's IDE. 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.
- mumblemumble 5y ago
  This seems like one of those spots where Smalltalk is a victim of cultural changes that happened around it. 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.
  - rileymat2 5y ago
    It is funny, one of the things that has bothered me for quite a while is that diffs don’t understand code. 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.
    - k1ll3r 5y ago
      you can write a diff tool that talks to an LSP server
    - nick__m 5y ago
      This tight integration between language and general purpose tool is a nice idea with a terrible price. It would make tools a lot harder to develop and they would be a lot slower as they now have to perform significantly more work.
    - rfw300 5y ago
einpoklum 5y ago
> a negative | (b between: c and: d) > ifTrue: [a := c negated] > 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.
morphle 5y ago
For me, a programmer who grew up with assembly language and Basic around 1980, Smalltalk is an extremely easy to read language. I have struggled with all the other languages (in the order of LISP, Forth, Pascal, Prolog, ADA, C/C++, Java, Perl, Python, Javascript, Scratch, Etoys). I have read the entire code base of Squeak Smalltalk (200.000 lines of code for the programming language, the operating system, GUI and IDE) and its the clearest and easiest to understand writing of a compleet system in history that I know of. I challenge anyone to prove to us any coding thats qualitatively better (than what Dan Ingalls wrote). 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 https://wiki.c2.com/?SmalltalkSyntax [2] https://squeak.org/documentation/terse_guide/ https://squeak.org/documentation/terse_guide/ [3] https://www.researchgate.net/publication/221501755_The_Early_History_of_Smalltalk https://www.researchgate.net/publication/221501755_The_Early... [4] https://www.teachthought.com/critical-thinking/cognitive-biases/ https://www.teachthought.com/critical-thinking/cognitive-bia... [5] https://cerebromente.org.br/n14/experimento/lorenz/index-lorenz.html https://cerebromente.org.br/n14/experimento/lorenz/index-lor... [6] https://www.researchgate.net/publication/220828937_OMeta_An_object-oriented_language_for_pattern_matching https://www.researchgate.net/publication/220828937_OMeta_An_... [7] https://smalltalkzoo.thechm.org/ https://smalltalkzoo.thechm.org/ [8] https://selflanguage.org/ https://selflanguage.org/ [9] https://squeak.js.org/ https://squeak.js.org/ [10] https://squeak.org/ https://squeak.org/ [11] Recent talks on youtube by Alan Kay [12] https://smalltalkzoo.thechm.org/papers/EvolutionOfSmalltalk.pdf https://smalltalkzoo.thechm.org/papers/EvolutionOfSmalltalk.... [13] https://ourself.io https://ourself.io
hota_mazi 5y ago
The Smalltalk syntax is pretty esoteric, but even if you become used to it, the fact that it requires all parameters to be named makes it an exceptionally verbose language that takes longer to parse in your head than most. 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).
- overgard 5y ago
  I think you have to separate out verbosity that adds clarity vs verbosity as ceremony. 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. Vs. t.rotate(v, 3.14/2) Sure the former is slightly more verbose (not by much though), but it tells me so much more and I don't need to look anything up. Also even though it's longer, none of it is fluff or ceremonial.
  - hota_mazi 5y ago
    You are trying to excuse Smalltalk's excessive verbosity by pointing out Java's excessive verbosity. 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.
    - igouy 5y ago
      Yes Smalltalk is verbose by design.
      - hota_mazi 5y ago
        Why would anyone think that a verbose language is a good idea? 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.
travisgriggs 5y ago
Disclaimer first… I was an avid Smalltalk advocate from 1992 until 2012. I worked at Cincom for 6 years. 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.
overgard 5y ago
Smalltalk is IMO super readable, it's just not familiar or standard. To me, unreadable languages are languages that rely heavily on symbols. The obvious extremes would be perl or APL. In those, if you don't already know the symbol it's pretty much impossible to figure out. In smalltalk, it tends to read like english so you can usually understand what it's doing even if you're not entirely familiar with the syntax. 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.
- RangerScience 5y ago
  Yup, symbols are the hardest. 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.
  - stirfish 5y ago
    The biggest advantage computer scientists have over mathematicians is that our variables can be more than one character
    - MaxBarraclough 5y ago
      Mathematicians allow multi-character identifiers when it comes to functions, though. sin, abs, det, etc.
      - Lhiw 5y ago
        Mathematicians just never left the "less characters = less typing" phase when it comes to variable names. I'm willing to bet a lot of it comes down to whiteboarding instead of writing it on a computer.
coldtea 5y ago
If you believe this, it's on you. If anything Smalltalk is easier to read than C++, as it has way less semantics. Probably closer to 1.4-era Java amount of semantics (but with far more power, e.g. closures for one). 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).
nickd2001 5y ago
To me its a bit like going on holiday and renting a car with the steering wheel on the other side. Takes a little getting used to, but whole populations can cope with driving on the right, or the left. Smalltalk has a beautiful simplicity, allowing one to express really complex ideas, which to me seems like a super-power. But being image-based can be a pain especially when working in large teams. Merging in everyone's changes could be a PITA.
- igouy 5y ago
  Unless you were using fine grained version control ENVY/Developer.

110 points by tjalfi 5y ago

Probably part of why Smalltalk died. The C syntax and the BASIC syntax became ubiquitous, and things like Pascal and Smalltalk were just too weird. Luckily we have Ruby, which is almost-Smalltalk with a BASIC-like syntax.

mseepgood 5y ago
Compared to C, Pascal has the less weird syntax.
VWWHFSfQ 5y ago
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. It seems like it has every syntax in there somewhere.
- api 5y ago
  That's a problem with LISP-style languages too. Too much flexibility and dynamic syntax leads to write-only languages, or at least languages that are write-only-by-the-original-author. 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.
- ferdowsi 5y ago
  The only way I've seen Ruby work professionally is by using tooling that prevents developers from getting too clever with creating write-only code.
- nauticacom 5y ago
  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 I'd say this is a plus, at least in certain dimensions. One of the best descriptions I've heard of Rails' ActiveSupport (a collection of extensions to built-in types included in Rails) is as a dialect of Ruby, one specific for developing web applications. Other domains could and should use different dialects.
- snek_case 5y ago
  IMO that's one of the biggest weaknesses of Ruby. The language offers lots of different ways to do the same thing. You can say that makes the language more expressive. Sure, but it also means as a newcomer, there's a lot more language features to learn about. It makes the language less approachable to outsiders. 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.
  - setpatchaddress 5y ago
    I think it’s much simpler than that. Ruby didn’t have good documentation in English until the mid-2000’s. Python was in use by the English-speaking world before the turn of the century. Documentation + you can generally understand it at a glance == total Python dominance. Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.
    - Jtsummers 5y ago
      > 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.
jacquesm 5y ago
Pascal is actually one of the few languages that is quite readable, even for novices to programming. That's no coincidence, it was designed that way.
- froh 5y ago
  Yes the only "weird" thing in pascal was pointers and pointer dereferencing with the caret ^ I loved pascal syntax.
  - jacquesm 5y ago
    Yes, C got that bit right. -> made a lot more sense.
    - pyjarrett 5y ago
      In Ada (Pascal derivative), there's implicit dereference so we just use it like normal, `A.B`.
      - renox 5y ago
        Which has pros and cons: a pointer indirection can be expensive so the potential additional cost is hidden and pointers semantic is so different than hiding their usage is a bit risky.. That said this simplify refactoring and is much less 'noisy' to read. My preference is Pascal style but with an @ instead of a ^ which feels a bit weird.
  - badsectoracula 5y ago
    The caret is because ↑ (arrow up, in case HN drops it) wasn't really "typeable" (or even available) in most computers. I'm not sure if Wirth's Pascal even had the caret - i do have an old book about Pascal which uses the arrow for pointers, but i remember seeing the caret in various dialects. 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.
fault1 5y ago
I think Smalltalk's demise was really from the fact that it was a entire environment that had to live in a virtual machine. 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.
- agumonkey 5y ago
  I think none of the reason applies but it's tongue in cheek.. I think it all points at cultural maturity. Same smalltalk today might be well received because machines are wide and fast and people have seen more languages. It's surely easier to show ST to py or js coder today now they've seen large syntax changes and paradigms (FP, async etc)
  - 7thaccount 5y ago
    Pharo is a Smalltalk, but they're ok with moving in new directions. 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.
    - igouy 5y ago
      Maybe IT already deployed https://www.cincomsmalltalk.com/main/successes/financial-services/jpmorgan/ https://www.cincomsmalltalk.com/main/successes/financial-ser...
      - 7thaccount 5y ago
        I think most users of Cincom Smalltalk (and other esoteric language users such as Volvo using Dyalog APL) occurs most often due to historical reasons. Please note that I don't think poorly of these languages and would use them over something like Java in my own pet projects any day.
pyjarrett 5y ago
> Pascal and Smalltalk were just too weird 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.
- formerly_proven 5y ago
  > - Why is this function returning "void"? This makes no sense, that's not a function. 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.
TurboHaskal 5y ago
I believe it was mostly economical circumstances just like the other poster said. People put up with everything as long as there is a market and they are getting paid. 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.
overgard 5y ago
I doubt it. C++ syntax is all of: bizarre, hideous, and ambiguous and yet it never limited C++ because at the end of the day C++ was extremely practical. Smalltalk didn't take off (Im not going to say died because it's not dead) because the development tools were expensive and the runtime was frequently not fast enough and you needed a very powerful for its time computer to use it. 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.
Tozen 5y ago
I also disagree with your assessment. Pascal has greater readability in comparison to C, so it's "weirdness" is in the sense that it's more verbose. Arguably, the inherent problem of C family languages is their terseness tends to make them more cryptic and symbolic. But because of their popularity, many have become used to the eccentricities. 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/ https://pharo.org/).

jayp1418 5y ago

I am not a programmer but can read Ada Language :D

agumonkey 5y ago
kudos you're an embedded problem solver
zerr 5y ago
When reading code, skimming is more important actually. C-like syntax (symbols instead of prose) makes skimming easy.

xkriva11 5y ago

Let me add a classic "tutorial": 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

Jtsummers 5y ago
That's literally from page 2 of this, you could at least state that you're quoting the document. Also, you missed a step. Before "ambiguity": t rotate by a around v; //Who needs commas?
alfu 5y ago
Why not compare it with t.rotate(rotateBy, around)? Could a,v used for many purposes and this example allows us to indicate their role for this specific call?
- Jtsummers 5y ago
  Because a and v would be more typical variable names than rotateBy and around. Note that the author did not change the variable names in the translation process, they left them alone. So you could drop any variable in there but the calling of rotate becomes clearer (subjective) by switching to keywords and no longer relies on programmer discipline to have good variable names. 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.
- msbarnett 5y ago
  Because those are names the caller decided upon, so they can just as easily misinform the reader as correctly educate them. The caller could have mistyped the call as t.rotate(around, rotateBy) and the error in the effect might seem very mysterious indeed. The beauty of keyword args is that the mapping of caller's name to function argument name is explicit, and therefore reads correctly or incorrectly immediately at the callsite t rotateBy: point around:degrees is obviously an error, without sending the reader to look up the definition. Compiler-enforced clarity rather than relying on every individual piece of client code to always name things well & never make a mistake.

nauticacom 5y ago

Snippets like this: account deposit: 100 dollars. are why I love Smalltalk (and its followers, e.g. Ruby). So much expressiveness, reading like a sentence. And Smalltalk even had the ingenuity to use period as a statement terminator, so it feels even more like a descriptive sentence describing the domain concept.

nmz 5y ago
Rebol takes things further by identifying $ as a datatype. account/deposit $100 Nobody cares about rebol but I always bring it up in terms of expressivity.
- dragonwriter 5y ago
  > Rebol takes things further by identifying $ as a datatype. Well, money! is a datatype, $ is a sigil that identifies a money! literal.
- nauticacom 5y ago
  Just took a quick look at Rebol and it looks interesting! I love languages that push the boundary of what they allow programs to "naturally" express
- carapace 5y ago
  Yeah, I have no idea why Rebol and Red aren't more popular. ( https://www.red-lang.org/ https://www.red-lang.org/ ) They pack such a bang for the buck it's almost embarrassing for other language/runtimes.
  - Jtsummers 5y ago
    Rebol itself is practically dead, no new release in a decade. It was also proprietary early on and a "weird" language (interesting, and good, but non-standard in so many ways that it was very niche). That killed its potential in the late 90s and early 00s when everyone was moving to open source scripting languages that filled the same niche, but with more conventional syntaxes and free access. 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.

rubyist5eva 5y ago

I can read Ruby and Smalltalk but C++ is like ancient hieroglyphics that require a PhD in classical studies or something.

nick__m 5y ago

I had the same problem in graduate school until I realized that Smalltalk is not designed to be read outside it's IDE. 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.

mumblemumble 5y ago
This seems like one of those spots where Smalltalk is a victim of cultural changes that happened around it. 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.
- rileymat2 5y ago
  It is funny, one of the things that has bothered me for quite a while is that diffs don’t understand code. 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.
  - k1ll3r 5y ago
    you can write a diff tool that talks to an LSP server
  - nick__m 5y ago
    This tight integration between language and general purpose tool is a nice idea with a terrible price. It would make tools a lot harder to develop and they would be a lot slower as they now have to perform significantly more work.
  - rfw300 5y ago

einpoklum 5y ago

> a negative | (b between: c and: d) > ifTrue: [a := c negated] > 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.

morphle 5y ago

For me, a programmer who grew up with assembly language and Basic around 1980, Smalltalk is an extremely easy to read language. I have struggled with all the other languages (in the order of LISP, Forth, Pascal, Prolog, ADA, C/C++, Java, Perl, Python, Javascript, Scratch, Etoys). I have read the entire code base of Squeak Smalltalk (200.000 lines of code for the programming language, the operating system, GUI and IDE) and its the clearest and easiest to understand writing of a compleet system in history that I know of. I challenge anyone to prove to us any coding thats qualitatively better (than what Dan Ingalls wrote). 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 https://wiki.c2.com/?SmalltalkSyntax [2] https://squeak.org/documentation/terse_guide/ https://squeak.org/documentation/terse_guide/ [3] https://www.researchgate.net/publication/221501755_The_Early_History_of_Smalltalk https://www.researchgate.net/publication/221501755_The_Early... [4] https://www.teachthought.com/critical-thinking/cognitive-biases/ https://www.teachthought.com/critical-thinking/cognitive-bia... [5] https://cerebromente.org.br/n14/experimento/lorenz/index-lorenz.html https://cerebromente.org.br/n14/experimento/lorenz/index-lor... [6] https://www.researchgate.net/publication/220828937_OMeta_An_object-oriented_language_for_pattern_matching https://www.researchgate.net/publication/220828937_OMeta_An_... [7] https://smalltalkzoo.thechm.org/ https://smalltalkzoo.thechm.org/ [8] https://selflanguage.org/ https://selflanguage.org/ [9] https://squeak.js.org/ https://squeak.js.org/ [10] https://squeak.org/ https://squeak.org/ [11] Recent talks on youtube by Alan Kay [12] https://smalltalkzoo.thechm.org/papers/EvolutionOfSmalltalk.pdf https://smalltalkzoo.thechm.org/papers/EvolutionOfSmalltalk.... [13] https://ourself.io https://ourself.io

hota_mazi 5y ago

The Smalltalk syntax is pretty esoteric, but even if you become used to it, the fact that it requires all parameters to be named makes it an exceptionally verbose language that takes longer to parse in your head than most. 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).

overgard 5y ago
I think you have to separate out verbosity that adds clarity vs verbosity as ceremony. 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. Vs. t.rotate(v, 3.14/2) Sure the former is slightly more verbose (not by much though), but it tells me so much more and I don't need to look anything up. Also even though it's longer, none of it is fluff or ceremonial.
- hota_mazi 5y ago
  You are trying to excuse Smalltalk's excessive verbosity by pointing out Java's excessive verbosity. 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.
  - igouy 5y ago
    Yes Smalltalk is verbose by design.
    - hota_mazi 5y ago
      Why would anyone think that a verbose language is a good idea? 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.

travisgriggs 5y ago

Disclaimer first… I was an avid Smalltalk advocate from 1992 until 2012. I worked at Cincom for 6 years. 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.

overgard 5y ago

Smalltalk is IMO super readable, it's just not familiar or standard. To me, unreadable languages are languages that rely heavily on symbols. The obvious extremes would be perl or APL. In those, if you don't already know the symbol it's pretty much impossible to figure out. In smalltalk, it tends to read like english so you can usually understand what it's doing even if you're not entirely familiar with the syntax. 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.

RangerScience 5y ago
Yup, symbols are the hardest. 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.
- stirfish 5y ago
  The biggest advantage computer scientists have over mathematicians is that our variables can be more than one character
  - MaxBarraclough 5y ago
    Mathematicians allow multi-character identifiers when it comes to functions, though. sin, abs, det, etc.
    - Lhiw 5y ago
      Mathematicians just never left the "less characters = less typing" phase when it comes to variable names. I'm willing to bet a lot of it comes down to whiteboarding instead of writing it on a computer.

coldtea 5y ago

If you believe this, it's on you. If anything Smalltalk is easier to read than C++, as it has way less semantics. Probably closer to 1.4-era Java amount of semantics (but with far more power, e.g. closures for one). 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).

nickd2001 5y ago

To me its a bit like going on holiday and renting a car with the steering wheel on the other side. Takes a little getting used to, but whole populations can cope with driving on the right, or the left. Smalltalk has a beautiful simplicity, allowing one to express really complex ideas, which to me seems like a super-power. But being image-based can be a pain especially when working in large teams. Merging in everyone's changes could be a PITA.

igouy 5y ago
Unless you were using fine grained version control ENVY/Developer.