home.social

#dylanlang — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #dylanlang, aggregated by home.social.

  1. In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

    My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

    But I still think there could be things the Scheme community would want to glean from this snapshot of history.

    I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

    [0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
    nhplace.com/kent/History/dylan

    [1] Ralph Conditions (part 1 of 2)
    nhplace.com/kent/History/dylan

    [2] Ralph Conditions (part 2 of 2)
    nhplace.com/kent/History/dylan

    cc @sigue @ramin_hal9001 @screwlisp

    #DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

  2. In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

    My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

    But I still think there could be things the Scheme community would want to glean from this snapshot of history.

    I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

    [0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
    nhplace.com/kent/History/dylan

    [1] Ralph Conditions (part 1 of 2)
    nhplace.com/kent/History/dylan

    [2] Ralph Conditions (part 2 of 2)
    nhplace.com/kent/History/dylan

    cc @sigue @ramin_hal9001 @screwlisp

    #DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

  3. In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

    My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

    But I still think there could be things the Scheme community would want to glean from this snapshot of history.

    I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

    [0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
    nhplace.com/kent/History/dylan

    [1] Ralph Conditions (part 1 of 2)
    nhplace.com/kent/History/dylan

    [2] Ralph Conditions (part 2 of 2)
    nhplace.com/kent/History/dylan

    cc @sigue @ramin_hal9001 @screwlisp

    #DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

  4. In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

    My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

    But I still think there could be things the Scheme community would want to glean from this snapshot of history.

    I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

    [0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
    nhplace.com/kent/History/dylan

    [1] Ralph Conditions (part 1 of 2)
    nhplace.com/kent/History/dylan

    [2] Ralph Conditions (part 2 of 2)
    nhplace.com/kent/History/dylan

    cc @sigue @ramin_hal9001 @screwlisp

    #DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

  5. In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

    My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

    But I still think there could be things the Scheme community would want to glean from this snapshot of history.

    I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

    [0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
    nhplace.com/kent/History/dylan

    [1] Ralph Conditions (part 1 of 2)
    nhplace.com/kent/History/dylan

    [2] Ralph Conditions (part 2 of 2)
    nhplace.com/kent/History/dylan

    cc @sigue @ramin_hal9001 @screwlisp

    #DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

  6. Un día alegre.
    #Dylanlang tiene una nueva versión opendylan.org/release-notes/20 en la que modestamente he participado.
    Muchas gracias a los Dylan #hackers que me dejan jugar en este lenguaje de #programación.

  7. In 2024/Jan/31 I did a PR to #github to add a .gitignore for #DylanLang. Two days ago a bot told me that this PR is staled and it will be close after 180 days of inactivity. I should leave a comment if I want to keep it open.

    What would you do?

  8. @sigue @nytpu

    > #DylanLang has separate functions for map, map-as, and do.

    That is certainly a justifiable different design approach (than #CommonLisp's).

    #ThereAreAlwaysTradeoffs

  9. CW: BIKE-SHEDDING

    In Dylan, the IF expression looks like this:

    if (test)
    true-expr
    else
    false-expr
    end

    (The true/false expressions can be any number of expressions but here I'm interested in the short case.)

    Generally I'm quite happy with this, but when there are a lot of very short conditionals in a function it can get too verbose.

    I have a macro that looks like this for such cases:

    iff(test, true-expr, false-expr)

    What should I call it?!

    #DylanLang #Lisp #BikeShedding

  10. Comments from the .proto file are now carried over to the .dylan file, and add-foo methods are created for repeated fields.

    github.com/cgay/protocol-buffe

    #DylanLang #ProtocolBuffers

  11. Comments from the .proto file are now carried over to the .dylan file, and add-foo methods are created for repeated fields.

    github.com/cgay/protocol-buffe

    #DylanLang #ProtocolBuffers

  12. Comments from the .proto file are now carried over to the .dylan file, and add-foo methods are created for repeated fields.

    github.com/cgay/protocol-buffe

    #DylanLang #ProtocolBuffers

  13. This commit contains the generated code for descriptor.proto. Dylan protobufs are now bootstrapped! (But lots more work to do.)

    github.com/cgay/protocol-buffe

    #DylanLang #ProtocolBuffers

  14. This commit contains the generated code for descriptor.proto. Dylan protobufs are now bootstrapped! (But lots more work to do.)

    github.com/cgay/protocol-buffe

    #DylanLang #ProtocolBuffers

  15. This commit contains the generated code for descriptor.proto. Dylan protobufs are now bootstrapped! (But lots more work to do.)

    github.com/cgay/protocol-buffe

    #DylanLang #ProtocolBuffers

  16. This commit contains the generated code for descriptor.proto. Dylan protobufs are now bootstrapped! (But lots more work to do.)

    github.com/cgay/protocol-buffe

    #DylanLang #ProtocolBuffers

  17. This commit contains the generated code for descriptor.proto. Dylan protobufs are now bootstrapped! (But lots more work to do.)

    github.com/cgay/protocol-buffe

    #DylanLang #ProtocolBuffers

  18. @Seanleblanc

    WRT #CommonLisp Object System (#CLOS):

    The seminal book ›The Art of the Metaobject protocol‹ (1991, #AMOP) by #Kiczales, #Rivieres & #Bobrow demonstrates & discusses many design patterns for #ObjectSystem|s with #metaobject protocol, in which methods are not part of classes, due to #multimethod, #multipledispatch paradigms.

    It also contributed much to #DylanLang.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Lisp #FamilyOfLisp #CLtL2 #CLHS #ELSConf #XEROXParc

  19. @Seanleblanc

    WRT #CommonLisp Object System (#CLOS):

    The seminal book ›The Art of the Metaobject protocol‹ (1991, #AMOP) by #Kiczales, #Rivieres & #Bobrow demonstrates & discusses many design patterns for #ObjectSystem|s with #metaobject protocol, in which methods are not part of classes, due to #multimethod, #multipledispatch paradigms.

    It also contributed much to #DylanLang.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Lisp #FamilyOfLisp #CLtL2 #CLHS #ELSConf #XEROXParc

  20. @Seanleblanc

    WRT #CommonLisp Object System (#CLOS):

    The seminal book ›The Art of the Metaobject protocol‹ (1991, #AMOP) by #Kiczales, #Rivieres & #Bobrow demonstrates & discusses many design patterns for #ObjectSystem|s with #metaobject protocol, in which methods are not part of classes, due to #multimethod, #multipledispatch paradigms.

    It also contributed much to #DylanLang.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Lisp #FamilyOfLisp #CLtL2 #CLHS #ELSConf #XEROXParc

  21. @Seanleblanc

    WRT #CommonLisp Object System (#CLOS):

    The seminal book ›The Art of the Metaobject protocol‹ (1991, #AMOP) by #Kiczales, #Rivieres & #Bobrow demonstrates & discusses many design patterns for #ObjectSystem|s with #metaobject protocol, in which methods are not part of classes, due to #multimethod, #multipledispatch paradigms.

    It also contributed much to #DylanLang.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Lisp #FamilyOfLisp #CLtL2 #CLHS #ELSConf #XEROXParc

  22. @Seanleblanc

    WRT #CommonLisp Object System (#CLOS):

    The seminal book ›The Art of the Metaobject protocol‹ (1991, #AMOP) by #Kiczales, #Rivieres & #Bobrow demonstrates & discusses many design patterns for #ObjectSystem|s with #metaobject protocol, in which methods are not part of classes, due to #multimethod, #multipledispatch paradigms.

    It also contributed much to #DylanLang.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Lisp #FamilyOfLisp #CLtL2 #CLHS #ELSConf #XEROXParc

  23. @Shou @ntnsndr @Paul030 @christina

    I'm also very much interested in establishing a #LispCoop, that is, a #cooperative of #freelancer|s focused on projects involving programming languages in the #FamilyOfLisp.

    The motivation is that #SoftwareDevelopment & #ProjectManagement need to observe sufficiently different aims, practices, paradigms and risks with #Lisp programming languages.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Scheme #CommonLisp #ELSConf #Clojure #DylanLang #CLHS

  24. @Shou @ntnsndr @Paul030 @christina

    I'm also very much interested in establishing a #LispCoop, that is, a #cooperative of #freelancer|s focused on projects involving programming languages in the #FamilyOfLisp.

    The motivation is that #SoftwareDevelopment & #ProjectManagement need to observe sufficiently different aims, practices, paradigms and risks with #Lisp programming languages.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Scheme #CommonLisp #ELSConf #Clojure #DylanLang #CLHS

  25. @Shou @ntnsndr @Paul030 @christina

    I'm also very much interested in establishing a #LispCoop, that is, a #cooperative of #freelancer|s focused on projects involving programming languages in the #FamilyOfLisp.

    The motivation is that #SoftwareDevelopment & #ProjectManagement need to observe sufficiently different aims, practices, paradigms and risks with #Lisp programming languages.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Scheme #CommonLisp #ELSConf #Clojure #DylanLang #CLHS

  26. @Shou @ntnsndr @Paul030 @christina

    I'm also very much interested in establishing a #LispCoop, that is, a #cooperative of #freelancer|s focused on projects involving programming languages in the #FamilyOfLisp.

    The motivation is that #SoftwareDevelopment & #ProjectManagement need to observe sufficiently different aims, practices, paradigms and risks with #Lisp programming languages.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Scheme #CommonLisp #ELSConf #Clojure #DylanLang #CLHS

  27. @Shou @ntnsndr @Paul030 @christina

    I'm also very much interested in establishing a #LispCoop, that is, a #cooperative of #freelancer|s focused on projects involving programming languages in the #FamilyOfLisp.

    The motivation is that #SoftwareDevelopment & #ProjectManagement need to observe sufficiently different aims, practices, paradigms and risks with #Lisp programming languages.

    🌺

    🦎 telegram.me/FamilyOfLisp
    🦎 matrix.to/#/#family-of-lisp:ma

    🏷️ #Scheme #CommonLisp #ELSConf #Clojure #DylanLang #CLHS