16 ms·

Dylan: A New Language Is Blowin' in the Wind (1992)

123 points by e12e 9y ago

coldtea 9y ago
Ah, if only Dylan and Smalltalk had survived the 90s.
- nine_k 9y ago
  You can think of Ruby or even Python as of Smalltalk survived, and of Erlang/Elixir as of Smalltalk's original vision implemented, to a degree.
  - pjmlp 9y ago
    It is not the same without the IDE/full blown OS experience.
  - coldtea 9y ago
    The whole point of Smalltalk is: 1) the integrated IDE/program experience, which Ruby, Python, Elixir do not give. 2) the totally orthogonal and very limited set of concepts that build up to the full language. Something that Ruby, Python and Elixir also don't have. In Smalltalk even a for, if etc statement is not something special to the language. In a way it has fewer special forms than
    - rothbardrand 9y ago
      Swift seems to have both those qualities, if I'm interpreting you correctly.
      - scroot 9y ago
        It's not the same. With a Smalltalk system, there isn't really an operating system. All activity we would normally ascribe to an OS is simply implement in the Smalltalk environment, using Smalltalk objects, running in a live image. I recommend checking out the Smalltalk-80 "Blue Book", which is beautifully written. You can also play with Pharo too, just be sure to understand that it's adapted for modern personal computers and therefore has to run as a virtual machine. A system that could run Smalltalk natively would be much better.
        0x8BADF00D 9y ago
        You can always run Emacs with Common Lisp. ;)
    - hota_mazi 9y ago
      > the integrated IDE/program experience, which Ruby, Python, Elixir do not give. True, but be aware that Java IDE's give you ten times more features and refactorings than Smalltalk IDE's can ever give you, because of the simple fact that Smalltalk is dynamically typed (which means it's pretty much impossible for them to provide automated refactorings: most of these need to be supervised by a human).
      - pjmlp 9y ago
        Refactoring tools appeared for the first time on Smalltalk. Eclipse was reborn from Visual Age for Smalltalk.
        hota_mazi 9y ago
        I am aware, my point still stands: the refactorings available in Java IDE's are more powerful, safer and more numerous than the Smalltalk IDE ever offered. Which shouldn't come as a surprise since Smalltalk is dynamically typed, which means automated refactorings are impossible to achieve without human supervision.
        coldtea 9y ago
        A Smalltalk image/IDE being dynamically typed doesn't mean anything, as it can have a full live-above-AST-level knowledge of everything in the program -- including the dynamic types of everything. Think of it as ten times the power of Java's reflection. What you can do in such a system (without human intervention) makes IntelliJ/Eclipse look like Pico.
        hota_mazi 9y ago
        I think you have no idea what the Smalltalk refactoring browser is actually capable of doing (and not doing). Please read this: https://news.ycombinator.com/item?id=15113804 https://news.ycombinator.com/item?id=15113804
- e12e 9y ago
  Going to repeat this here: A reminder to others, and a note-to-self that readable-lisp exists: http://wiki.c2.com/?SweetExpressions http://wiki.c2.com/?SweetExpressions The wiki page makes a valid point; seemingly heavy lisp users will argue against non-s-expression syntax, but happily use prefix notation for quote, and infix for pairs...
  - vanderZwan 9y ago
    Do I read that correctly as implying sweet expressions are bijective with s-expressions? Hoe many Lisp dialects have support for them?
    - e12e 9y ago
      Pretty much. Lisp programmers seem to think writing ast with parentheses is somehow superior to other syntax (except when it comes to quote and dot) - while what you really need is a good way to manipulate the ast (for good/easy macro support). The common lisp variant is pretty broadly supported afaik - and there's a scheme variant and a #language for racket: https://docs.racket-lang.org/sweet/index.html https://docs.racket-lang.org/sweet/index.html Still, if what you want is "sane" (IMNHO) syntax - you're probably better off using Julia. I don't know why a dylan-like subletting of common lisp/clos hasn't been more successful. Maybe people just love different corners of the common lisp spec too much?
      - lispm 9y ago
        > while what you really need need for what? > is a good way to manipulate the ast (for good/easy macro support). S-expressions were not initially used in Lisp because of macros. Actually the early Lisp had no macros, but s-expressions. They were used as a syntax and representation for lists and tree-like data. s-expressions were first used as a data representation and people had to use it, because programs were represented as s-expressions. The programs were written as m-expressions in some algebraic notation, but had to be translated to s-expressions to be executed by Lisp. The expectation was that s-expressions were only an implementation detail and programmers were then using some other syntax for their programs. There were some larger efforts to design a successor to Lisp 1.5 (called Lisp 2) with such a syntax and have that as the default/main Lisp dialect. Eventually this project was cancelled. http://www.softwarepreservation.org/projects/LISP/lisp2_family/ http://www.softwarepreservation.org/projects/LISP/lisp2_fami... The advantages of s-expressions in the context of Lisp were/are: * not dependent on line-based data entry and not sensitive to whitespace * one could easily feed code as s-expressions to a interpreter, this could be a Lisp interpreter, or an interpreter for some other language using s-expressions. * the parsing/scanning/printing/formatting of s-expressions is reusable in different contexts. this can be done with or without knowing the contents of s-expressions. One can easily format s-expressions based on general rules, but one can also write special purpose code formatter for Lisp. Lisp has this built-in with the pretty-printer. * generally writing code transformations (not just Lisp macros) is a bit easier with richer data structures than strings. For example write a bunch of rules using s-expression and transform/interpret them. Thus different interpreters/compilers can be easily written, not just a Lisp interpreter/compiler. * interactive manipulation of s-expressions and s-expression-based code is relatively easy. This helps a lot with REPL-style programming. Marking (sub-)expressions, transposing them, replacing/moving them, then gets relatively easy. You'll get a poor-man's syntax directed editing very easy. If you want in an IDE make a Java-expression available broken up into its subexpressions, one has to use a much more complicated parser, which then has very detailed knowledge about the language - which is both and good. With s-expressions you still get some structure editing, while on that level there is very little commitment about the syntax of the actual contents (is it a Lisp program? Is it a bunch of rules for a firewall? is it a list of diagnosis rules?). Syntax-directed editing is available in many tools, but rarely is it as interactive and basic as in Lisp with s-expression syntax, which is also very robust against accidentally reformatting (omitted newlines, added whitespace, ...). Enter an s-expression and its always easy to reconstruct the visual structure. Since (sub-)expressions are delimited left and right with characters ( and ), it's always clear where it starts and ends when displayed or read. With a syntax with less visual structure or one which needs to be reconstructed with a parser, this is much more difficult and less intuitive to use.
- protomyth 9y ago
  I'm pretty sure the Pharo folks would say Smalltalk isn't dead yet. http://pharo.org/ http://pharo.org/ https://www.pharocloud.com/ https://www.pharocloud.com/
  - coldtea 9y ago
    Yes they could say it, but popularity and support wise it wouldn't mean much. Survived = at least at the same level of use as Ruby, Python, PHP, etc -- or at least Go and Rust.
    - protomyth 9y ago
      I know its still used in several companies. One of which is quite busy this time of year. One of Smalltalk's big problems was the companies using it aren't very talkative about what they use. Smalltalk is in a lot of the back ends keeping things moving. Cincom and others still make a lot of cash off it.
    - agumonkey 9y ago
      Unfair to compare to PHP and Ruby who blossomed because of the web. Go and Rust are recent and massively backed. I did a Pharo MOOC last year, ST is far from dead, it's "streets ahead" in many department its not even funny.
      - int_19h 9y ago
        Fairness is inherently out of scope in such comparisons.
        agumonkey 9y ago
        I just changed that rule.
  - hota_mazi 9y ago
    "isn't dead" is a very low bar. COBOL and Fortran are not dead as long as there's still at least one person on the planet writing code in it. "Failed to gain acceptance" is a more realistic criterion, and Lisp and Smalltalk clearly did that.
- hota_mazi 9y ago
  They didn't survive for good reasons. They had interesting ideas and concepts that were reused in later languages, but at the end of the day, the strength of a language is not just its syntax and semantics. Java and C# won this war for a legitimate reason.
  - klibertp 9y ago
    > a legitimate reason. Which is? Please don't keep us in the dark, you obviously know something most of us never heard of.
    - hota_mazi 9y ago
      The tooling ecosystem, the performance, the VM, the GC, the libraries, etc... Also, Smalltalk is dynamically typed so there are very few refactorings that can be performed safely without the supervision of a human.
      - scroot 9y ago
        > The tooling ecosystem, the performance, the VM, the GC, the libraries, etc... None of that emerged from whole cloth in the beginning. It's the result of time and wide adoption. Java was released for free. Smalltalk wasn't.
      - klibertp 9y ago
        > The tooling ecosystem Smalltalk single-handedly invented "the tooling", thanks to the various "browsers" and refactoring and testing tools, all made possible because of the dynamic nature of the language, which made the code almost its own runtime representation. > the performance Smalltalk pioneered many JIT techniques in the early '80s. > the VM, the GC All Smalltalks, as far as I can tell, are garbage-collected and run in VMs. > the libraries As a sibling comment states, that's what you get after decades of usage; can you tell with any certainty that Smalltalk would have less libraries, were it popular for longer? (Actually, there are objective problems with distributing libraries in Smalltalk, stemming from its "everything in global namespace" nature; there were many systems designed to alleviate this problem.) > is dynamically typed so there are very few refactorings that can be performed safely without the supervision of a human I'm afraid you don't understand Smalltalk environment in full. In an ordinary language, the code you write is just text. The type system adds certain information to the bits of text on your screen and prevents you - via compiler errors - from arranging the pieces of text in a way which would probably make the program explode when run. It works most of the time, except when it doesn't and you end up passing void pointers and Object references. In effect, instead of only dealing with the type system, you have to deal with both static types and runtime behavior. I guess you just like it. When working with Smalltalk, however, you work in a live environment. In Smalltalk, there is no source. Whatever you write is not just text - it's alive, then and there, and the system can trace each identifier and get its runtime type as you type, including concrete types of polymorphic types and other constructs frequently impossible to check with a static type checker in most languages. In effect, Smalltalk gives you more contextual information to work with than most statically typed languages. Were you ever puzzled about which overload of a method (of polymorphic classes) will be called in a particular scenario? In Smalltalk, you can just ask the system and it will tell you. Coupled with other features of the language this makes it really easy to perform automated refactorings. As others noted, the very notion of automated refactorings come from Smalltalk. I'm not very familiar with Java tooling, but I'd be really surprised if it enabled anything more than what Smalltalks offer. In summary: static type systems are not the only way of adding contextual data to the source. There are other, arguably more powerful (access to the "real" runtime types) ways of doing it, and Smalltalk implements one of it. Don't worry, though - the misconceptions you hold are very popular and it's not your fault for believing them. The problem with programming is that it evolves pretty rapidly, with many approaches failing along the way, that it's rather impossible to provide a comprehensive summary of the best ideas; and without such a summary we rely mostly on gossip. Moreover, the benefits of some approaches are very hard to grasp without experiencing them first-hand, and who has the time for that?
- gumby 9y ago
  Smalltalk sort of survived in the Smalltalk-inspired Objective C. Although in the end Stepstone left out the dynamism that was the best part of Smalltalk on the D machine.
thomasjudge 9y ago
"C++ is the COBOL of the 90's" - Jeff Alger
- zerr 9y ago
  Is this from C++ For Real Programmers? :) a nice book by Jeff. I wonder what's he's up nowadays.
- int_19h 9y ago
  I'm pretty sure that Java is the COBOL of 90s (and 00s, for that matter).
dasmoth 9y ago
The implementation was open-sourced and had a fair amount of work put into modernising it. Things seem to have gone quiet the last couple of years, but it's out there if anyone wants to try it: https://opendylan.org/ https://opendylan.org/
- lispm 9y ago
  This is not Apple's Dylan implementation, but Harlequin's. Apple's implementation has not been published, AFAIK.
  - dasmoth 9y ago
    Thanks. I've never really been clear on the relationship between Harlequin and Apple on Dylan stuff -- were they totally separate impls?
    - lispm 9y ago
      Yes, completely different. Apple's Dylan implementation was written in Macintosh Common Lisp. Harlequin started with a LispWorks-based implementation and then had an all-in-Dylan implementation. This is the old Common Lisp / LispWorks implementation of Dylan from Harlequin: https://github.com/dylan-lang/opendylan/tree/5f9225d246d771cfaa2fa4f255a4447bff6991b8/old/Sources/emulator https://github.com/dylan-lang/opendylan/tree/5f9225d246d771c...
deleted 9y ago
[deleted]
st3fan 9y ago
Too bad Dylan never made it to the Newton. I’m actually not sure that was ever the intention. Dylan was pretty heavy weight?
- osteele 9y ago
  That was definitely the intention. It was intended as a systems and application programming language for the Newton. The original Apple implementation compiled to native ARM code. The runtime was intended to be competitive with C, but by the time we approached that target, large parts of the toolbox had already been written in C, and Walter Smith had created NewtonScript as a scripting language that worked as an alternative for non-performance-critical code. At that point the Cambridge team re-targetted the implementation to build Macintosh applications, but that wasn't a sufficiently compelling (to Apple management) use, and we had lost our executive sponsor when the director of the Apple Cambridge lab was promoted to a position in Cupertino. For those curious about Dylan's history, the Wikipedia page https://en.wikipedia.org/wiki/History_of_the_Dylan_programming_language https://en.wikipedia.org/wiki/History_of_the_Dylan_programmi... looks correct. (I'm the “Oliver Steele” mentioned on that page. I went to Apple Dylan from Skia – later released as Quickdraw GX – another technology that missed the Newton boat.)
  - kabdib 9y ago
    Well, I ported Skia's memory manager to the Newton, and added some tricks to make it more friendly to the Newton's virtual memory system. So some of Skia made it over ... :_) The dropping of Dylan was a little more nuanced and maybe somewhat nasty. The decision was made to ship "junior" (the handheld unit that became the MessagePad 100) using C++, while work was still being done in Dylan on "senior", the tablet unit. Eventually the Junior project grew in importance ("Holy crap, we have to ship this in a year") and it was all hands on deck to get it out the door. For a while there were a bunch of Dylan programmers roaming the hallways, they were clutching copies of the C++ Annotated Reference Manual and looking really unhappy. The writing was on the wall, Senior got canceled a few months later and a bunch of the Dylan folks quit.
    - 9y ago
ekidd 9y ago
Ah, Dylan was a ton of fun. First, some personal background: When I was an intern at Harlequin, I was one of the first users of Harlequin Dylan. Later, when CMU stopped work on Gwydion Dylan, I helped start an open source project to maintain it. And when Harlequin wanted to start open sourcing their Dylan (which later became https://opendylan.org/ https://opendylan.org/ ), I met with them to help hammer out licensing details. Harlequin released a lot of cool code. What was cool about Dylan? Well, it was a basically a relative of Common Lisp, but with an infix syntax, but it had been simplified to improve code performance. It was a more ambitious language than Java, with full closures, basic macros, and generic functions. Dylan had static typing if you wanted it, or you could leave code untyped. (Unfortunately, collection and function types were fairly weak due to the lack of standardized generic types.) In the end, Apple's abandonment of Dylan and the rise of Java united to make Dylan irrelevant. But it was a fun language, and I had a lot of fun hacking in it. I think that the closest popular language at the moment, design-wise, is probably Julia. I still remember one 20-hour day that where a friend and I set up tower computers in a cozy basement room at Dartmouth, and I eventually convinced the Gwydian FFI tool to parse 10,000 lines of Linux headers.
dasmoth 9y ago
David Moon designed a post-Dylan language called PLOT: http://users.rcn.com/david-moon/PLOT/ http://users.rcn.com/david-moon/PLOT/ (Not implemented as far as I know)
- mikelevins 9y ago
  I think you're right. Moon and I exchanged a little mail about it a few years ago. He wrote to tell me he liked Bard, my Dylan-influenced Lisp, and I think he said PLOT wasn't implemented. Interestingly, he also said he had a solution to class linearization that was superior to C3, but that he couldn't remember the details. I asked for more information, but he said that if he still had the notes they were in the attic or something. I'd still like to see his solution.
  - dasmoth 9y ago
    Thanks for pointing out Bard, I'll take a look!
    - mikelevins 9y ago
      It's dormant right now. I've been busy with other things. I do plan to start work on an updated version soon. Feel free to mail me at mikel at evins dot net if you want to chat about Bard.

123 points by e12e 9y ago

coldtea 9y ago

Ah, if only Dylan and Smalltalk had survived the 90s.

nine_k 9y ago
You can think of Ruby or even Python as of Smalltalk survived, and of Erlang/Elixir as of Smalltalk's original vision implemented, to a degree.
- pjmlp 9y ago
  It is not the same without the IDE/full blown OS experience.
- coldtea 9y ago
  The whole point of Smalltalk is: 1) the integrated IDE/program experience, which Ruby, Python, Elixir do not give. 2) the totally orthogonal and very limited set of concepts that build up to the full language. Something that Ruby, Python and Elixir also don't have. In Smalltalk even a for, if etc statement is not something special to the language. In a way it has fewer special forms than
  - rothbardrand 9y ago
    Swift seems to have both those qualities, if I'm interpreting you correctly.
    - scroot 9y ago
      It's not the same. With a Smalltalk system, there isn't really an operating system. All activity we would normally ascribe to an OS is simply implement in the Smalltalk environment, using Smalltalk objects, running in a live image. I recommend checking out the Smalltalk-80 "Blue Book", which is beautifully written. You can also play with Pharo too, just be sure to understand that it's adapted for modern personal computers and therefore has to run as a virtual machine. A system that could run Smalltalk natively would be much better.
      - 0x8BADF00D 9y ago
        You can always run Emacs with Common Lisp. ;)
  - hota_mazi 9y ago
    > the integrated IDE/program experience, which Ruby, Python, Elixir do not give. True, but be aware that Java IDE's give you ten times more features and refactorings than Smalltalk IDE's can ever give you, because of the simple fact that Smalltalk is dynamically typed (which means it's pretty much impossible for them to provide automated refactorings: most of these need to be supervised by a human).
    - pjmlp 9y ago
      Refactoring tools appeared for the first time on Smalltalk. Eclipse was reborn from Visual Age for Smalltalk.
      - hota_mazi 9y ago
        I am aware, my point still stands: the refactorings available in Java IDE's are more powerful, safer and more numerous than the Smalltalk IDE ever offered. Which shouldn't come as a surprise since Smalltalk is dynamically typed, which means automated refactorings are impossible to achieve without human supervision.
        coldtea 9y ago
        A Smalltalk image/IDE being dynamically typed doesn't mean anything, as it can have a full live-above-AST-level knowledge of everything in the program -- including the dynamic types of everything. Think of it as ten times the power of Java's reflection. What you can do in such a system (without human intervention) makes IntelliJ/Eclipse look like Pico.
        hota_mazi 9y ago
        I think you have no idea what the Smalltalk refactoring browser is actually capable of doing (and not doing). Please read this: https://news.ycombinator.com/item?id=15113804 https://news.ycombinator.com/item?id=15113804
e12e 9y ago
Going to repeat this here: A reminder to others, and a note-to-self that readable-lisp exists: http://wiki.c2.com/?SweetExpressions http://wiki.c2.com/?SweetExpressions The wiki page makes a valid point; seemingly heavy lisp users will argue against non-s-expression syntax, but happily use prefix notation for quote, and infix for pairs...
- vanderZwan 9y ago
  Do I read that correctly as implying sweet expressions are bijective with s-expressions? Hoe many Lisp dialects have support for them?
  - e12e 9y ago
    Pretty much. Lisp programmers seem to think writing ast with parentheses is somehow superior to other syntax (except when it comes to quote and dot) - while what you really need is a good way to manipulate the ast (for good/easy macro support). The common lisp variant is pretty broadly supported afaik - and there's a scheme variant and a #language for racket: https://docs.racket-lang.org/sweet/index.html https://docs.racket-lang.org/sweet/index.html Still, if what you want is "sane" (IMNHO) syntax - you're probably better off using Julia. I don't know why a dylan-like subletting of common lisp/clos hasn't been more successful. Maybe people just love different corners of the common lisp spec too much?
    - lispm 9y ago
      > while what you really need need for what? > is a good way to manipulate the ast (for good/easy macro support). S-expressions were not initially used in Lisp because of macros. Actually the early Lisp had no macros, but s-expressions. They were used as a syntax and representation for lists and tree-like data. s-expressions were first used as a data representation and people had to use it, because programs were represented as s-expressions. The programs were written as m-expressions in some algebraic notation, but had to be translated to s-expressions to be executed by Lisp. The expectation was that s-expressions were only an implementation detail and programmers were then using some other syntax for their programs. There were some larger efforts to design a successor to Lisp 1.5 (called Lisp 2) with such a syntax and have that as the default/main Lisp dialect. Eventually this project was cancelled. http://www.softwarepreservation.org/projects/LISP/lisp2_family/ http://www.softwarepreservation.org/projects/LISP/lisp2_fami... The advantages of s-expressions in the context of Lisp were/are: * not dependent on line-based data entry and not sensitive to whitespace * one could easily feed code as s-expressions to a interpreter, this could be a Lisp interpreter, or an interpreter for some other language using s-expressions. * the parsing/scanning/printing/formatting of s-expressions is reusable in different contexts. this can be done with or without knowing the contents of s-expressions. One can easily format s-expressions based on general rules, but one can also write special purpose code formatter for Lisp. Lisp has this built-in with the pretty-printer. * generally writing code transformations (not just Lisp macros) is a bit easier with richer data structures than strings. For example write a bunch of rules using s-expression and transform/interpret them. Thus different interpreters/compilers can be easily written, not just a Lisp interpreter/compiler. * interactive manipulation of s-expressions and s-expression-based code is relatively easy. This helps a lot with REPL-style programming. Marking (sub-)expressions, transposing them, replacing/moving them, then gets relatively easy. You'll get a poor-man's syntax directed editing very easy. If you want in an IDE make a Java-expression available broken up into its subexpressions, one has to use a much more complicated parser, which then has very detailed knowledge about the language - which is both and good. With s-expressions you still get some structure editing, while on that level there is very little commitment about the syntax of the actual contents (is it a Lisp program? Is it a bunch of rules for a firewall? is it a list of diagnosis rules?). Syntax-directed editing is available in many tools, but rarely is it as interactive and basic as in Lisp with s-expression syntax, which is also very robust against accidentally reformatting (omitted newlines, added whitespace, ...). Enter an s-expression and its always easy to reconstruct the visual structure. Since (sub-)expressions are delimited left and right with characters ( and ), it's always clear where it starts and ends when displayed or read. With a syntax with less visual structure or one which needs to be reconstructed with a parser, this is much more difficult and less intuitive to use.
protomyth 9y ago
I'm pretty sure the Pharo folks would say Smalltalk isn't dead yet. http://pharo.org/ http://pharo.org/ https://www.pharocloud.com/ https://www.pharocloud.com/
- coldtea 9y ago
  Yes they could say it, but popularity and support wise it wouldn't mean much. Survived = at least at the same level of use as Ruby, Python, PHP, etc -- or at least Go and Rust.
  - protomyth 9y ago
    I know its still used in several companies. One of which is quite busy this time of year. One of Smalltalk's big problems was the companies using it aren't very talkative about what they use. Smalltalk is in a lot of the back ends keeping things moving. Cincom and others still make a lot of cash off it.
  - agumonkey 9y ago
    Unfair to compare to PHP and Ruby who blossomed because of the web. Go and Rust are recent and massively backed. I did a Pharo MOOC last year, ST is far from dead, it's "streets ahead" in many department its not even funny.
    - int_19h 9y ago
      Fairness is inherently out of scope in such comparisons.
      - agumonkey 9y ago
        I just changed that rule.
- hota_mazi 9y ago
  "isn't dead" is a very low bar. COBOL and Fortran are not dead as long as there's still at least one person on the planet writing code in it. "Failed to gain acceptance" is a more realistic criterion, and Lisp and Smalltalk clearly did that.
hota_mazi 9y ago
They didn't survive for good reasons. They had interesting ideas and concepts that were reused in later languages, but at the end of the day, the strength of a language is not just its syntax and semantics. Java and C# won this war for a legitimate reason.
- klibertp 9y ago
  > a legitimate reason. Which is? Please don't keep us in the dark, you obviously know something most of us never heard of.
  - hota_mazi 9y ago
    The tooling ecosystem, the performance, the VM, the GC, the libraries, etc... Also, Smalltalk is dynamically typed so there are very few refactorings that can be performed safely without the supervision of a human.
    - scroot 9y ago
      > The tooling ecosystem, the performance, the VM, the GC, the libraries, etc... None of that emerged from whole cloth in the beginning. It's the result of time and wide adoption. Java was released for free. Smalltalk wasn't.
    - klibertp 9y ago
      > The tooling ecosystem Smalltalk single-handedly invented "the tooling", thanks to the various "browsers" and refactoring and testing tools, all made possible because of the dynamic nature of the language, which made the code almost its own runtime representation. > the performance Smalltalk pioneered many JIT techniques in the early '80s. > the VM, the GC All Smalltalks, as far as I can tell, are garbage-collected and run in VMs. > the libraries As a sibling comment states, that's what you get after decades of usage; can you tell with any certainty that Smalltalk would have less libraries, were it popular for longer? (Actually, there are objective problems with distributing libraries in Smalltalk, stemming from its "everything in global namespace" nature; there were many systems designed to alleviate this problem.) > is dynamically typed so there are very few refactorings that can be performed safely without the supervision of a human I'm afraid you don't understand Smalltalk environment in full. In an ordinary language, the code you write is just text. The type system adds certain information to the bits of text on your screen and prevents you - via compiler errors - from arranging the pieces of text in a way which would probably make the program explode when run. It works most of the time, except when it doesn't and you end up passing void pointers and Object references. In effect, instead of only dealing with the type system, you have to deal with both static types and runtime behavior. I guess you just like it. When working with Smalltalk, however, you work in a live environment. In Smalltalk, there is no source. Whatever you write is not just text - it's alive, then and there, and the system can trace each identifier and get its runtime type as you type, including concrete types of polymorphic types and other constructs frequently impossible to check with a static type checker in most languages. In effect, Smalltalk gives you more contextual information to work with than most statically typed languages. Were you ever puzzled about which overload of a method (of polymorphic classes) will be called in a particular scenario? In Smalltalk, you can just ask the system and it will tell you. Coupled with other features of the language this makes it really easy to perform automated refactorings. As others noted, the very notion of automated refactorings come from Smalltalk. I'm not very familiar with Java tooling, but I'd be really surprised if it enabled anything more than what Smalltalks offer. In summary: static type systems are not the only way of adding contextual data to the source. There are other, arguably more powerful (access to the "real" runtime types) ways of doing it, and Smalltalk implements one of it. Don't worry, though - the misconceptions you hold are very popular and it's not your fault for believing them. The problem with programming is that it evolves pretty rapidly, with many approaches failing along the way, that it's rather impossible to provide a comprehensive summary of the best ideas; and without such a summary we rely mostly on gossip. Moreover, the benefits of some approaches are very hard to grasp without experiencing them first-hand, and who has the time for that?
gumby 9y ago
Smalltalk sort of survived in the Smalltalk-inspired Objective C. Although in the end Stepstone left out the dynamism that was the best part of Smalltalk on the D machine.

thomasjudge 9y ago

"C++ is the COBOL of the 90's" - Jeff Alger

zerr 9y ago
Is this from C++ For Real Programmers? :) a nice book by Jeff. I wonder what's he's up nowadays.
int_19h 9y ago
I'm pretty sure that Java is the COBOL of 90s (and 00s, for that matter).

dasmoth 9y ago

The implementation was open-sourced and had a fair amount of work put into modernising it. Things seem to have gone quiet the last couple of years, but it's out there if anyone wants to try it: https://opendylan.org/ https://opendylan.org/

lispm 9y ago
This is not Apple's Dylan implementation, but Harlequin's. Apple's implementation has not been published, AFAIK.
- dasmoth 9y ago
  Thanks. I've never really been clear on the relationship between Harlequin and Apple on Dylan stuff -- were they totally separate impls?
  - lispm 9y ago
    Yes, completely different. Apple's Dylan implementation was written in Macintosh Common Lisp. Harlequin started with a LispWorks-based implementation and then had an all-in-Dylan implementation. This is the old Common Lisp / LispWorks implementation of Dylan from Harlequin: https://github.com/dylan-lang/opendylan/tree/5f9225d246d771cfaa2fa4f255a4447bff6991b8/old/Sources/emulator https://github.com/dylan-lang/opendylan/tree/5f9225d246d771c...

deleted 9y ago

[deleted]

st3fan 9y ago

Too bad Dylan never made it to the Newton. I’m actually not sure that was ever the intention. Dylan was pretty heavy weight?

osteele 9y ago
That was definitely the intention. It was intended as a systems and application programming language for the Newton. The original Apple implementation compiled to native ARM code. The runtime was intended to be competitive with C, but by the time we approached that target, large parts of the toolbox had already been written in C, and Walter Smith had created NewtonScript as a scripting language that worked as an alternative for non-performance-critical code. At that point the Cambridge team re-targetted the implementation to build Macintosh applications, but that wasn't a sufficiently compelling (to Apple management) use, and we had lost our executive sponsor when the director of the Apple Cambridge lab was promoted to a position in Cupertino. For those curious about Dylan's history, the Wikipedia page https://en.wikipedia.org/wiki/History_of_the_Dylan_programming_language https://en.wikipedia.org/wiki/History_of_the_Dylan_programmi... looks correct. (I'm the “Oliver Steele” mentioned on that page. I went to Apple Dylan from Skia – later released as Quickdraw GX – another technology that missed the Newton boat.)
- kabdib 9y ago
  Well, I ported Skia's memory manager to the Newton, and added some tricks to make it more friendly to the Newton's virtual memory system. So some of Skia made it over ... :_) The dropping of Dylan was a little more nuanced and maybe somewhat nasty. The decision was made to ship "junior" (the handheld unit that became the MessagePad 100) using C++, while work was still being done in Dylan on "senior", the tablet unit. Eventually the Junior project grew in importance ("Holy crap, we have to ship this in a year") and it was all hands on deck to get it out the door. For a while there were a bunch of Dylan programmers roaming the hallways, they were clutching copies of the C++ Annotated Reference Manual and looking really unhappy. The writing was on the wall, Senior got canceled a few months later and a bunch of the Dylan folks quit.
  - 9y ago

ekidd 9y ago

Ah, Dylan was a ton of fun. First, some personal background: When I was an intern at Harlequin, I was one of the first users of Harlequin Dylan. Later, when CMU stopped work on Gwydion Dylan, I helped start an open source project to maintain it. And when Harlequin wanted to start open sourcing their Dylan (which later became https://opendylan.org/ https://opendylan.org/ ), I met with them to help hammer out licensing details. Harlequin released a lot of cool code. What was cool about Dylan? Well, it was a basically a relative of Common Lisp, but with an infix syntax, but it had been simplified to improve code performance. It was a more ambitious language than Java, with full closures, basic macros, and generic functions. Dylan had static typing if you wanted it, or you could leave code untyped. (Unfortunately, collection and function types were fairly weak due to the lack of standardized generic types.) In the end, Apple's abandonment of Dylan and the rise of Java united to make Dylan irrelevant. But it was a fun language, and I had a lot of fun hacking in it. I think that the closest popular language at the moment, design-wise, is probably Julia. I still remember one 20-hour day that where a friend and I set up tower computers in a cozy basement room at Dartmouth, and I eventually convinced the Gwydian FFI tool to parse 10,000 lines of Linux headers.

dasmoth 9y ago

David Moon designed a post-Dylan language called PLOT: http://users.rcn.com/david-moon/PLOT/ http://users.rcn.com/david-moon/PLOT/ (Not implemented as far as I know)

mikelevins 9y ago
I think you're right. Moon and I exchanged a little mail about it a few years ago. He wrote to tell me he liked Bard, my Dylan-influenced Lisp, and I think he said PLOT wasn't implemented. Interestingly, he also said he had a solution to class linearization that was superior to C3, but that he couldn't remember the details. I asked for more information, but he said that if he still had the notes they were in the attic or something. I'd still like to see his solution.
- dasmoth 9y ago
  Thanks for pointing out Bard, I'll take a look!
  - mikelevins 9y ago
    It's dormant right now. I've been busy with other things. I do plan to start work on an updated version soon. Feel free to mail me at mikel at evins dot net if you want to chat about Bard.