4 ms·

Envy/Developer was in heavy use where I worked, and it was pretty great but still nothing like the packagement management tools we now have. I'd say the change

Envy/Developer was in heavy use where I worked, and it was pretty great but still nothing like the packagement management tools we now have. I'd say the change log in something like VisualWorks was definitely not git-able in any way that would facilitate merging of several developers code. In fact it was extremely difficult to keep images in sync without something like Envy/Developer. Lisp to me is like a fascinating fossil.

neilv 4y ago
When I used ParcPlace Objectworks Smalltalk 4.1. and then VisualWorks Smalltalk in the early '90s, you'd use a menu item to write a human-readable ASCII serialization of some part of the system (not changelog) to the host filesystem. And it'd be diffable and mergeable and loadable. Doing Git with just that seems only a little different than what we'd do with a collection of source files today in some other language, including branches and merges. At the same time, one commercial site I worked at was doing its SCM for C code using kludge scripts over SCCS to an NFS volume. The next was putting C and C++ into Apollo DSEE and making SPARCstations jump through hoops to use that (because ancient DSEE on some Apollo DN10ks for SCM and CI/CD was better than the state of the art almost everyone else was using) and my advanced R&D group had just gotten DSEE-descendant Atria ClearCase for greenfield work in C++ from our Sun and HP workstations. The next site was using some dumpster fire of `.BAT` scripts over Perforce(?) for Windows NT-dominated C++ development. I'd say VisualWorks Smalltalk's wasn't the problem for team development at the time. The state of practice of everything else was more the problem.
User23 4y ago
> Lisp to me is like a fascinating fossil. Evidently you have some experience with Smalltalk, but what makes you say that about Lisp? Also which Lisp exactly do you have in mind? To me the Lisp family of languages is more like Classical music: it doesn’t satisfy some modern sensibilities, but it has a timeless elegance and will be around long after the latest fad is gone.
- smackeyacky 4y ago
  It's a personal opinion more than anything. I see Clojure getting attention but it isn't going to replace Node.js or .NET any time soon. The major difference being the ecosystem built around something like C# is miles ahead of anything available for even Clojure. Some people might think that's an advantage, but for people like me whose job is to be pragmatic and "git er dun" it's a major impediment. Hence, lisp has become a kind of toy from a golden age. I find myself reaching for C# or Python for experiments. I have dabbled in lisp occasionally over the years but never found Clojure very compelling.
  - armitron 4y ago
    You come across as someone with minimal -if any- experience with Lisp, to be making some of the generalizations and grandiose proclamations that you do. Also, lots of people don't consider Clojure a Lisp.
    - shaunxcode 4y ago
      I, for one, consider Clojure a lisp. And I have a physical copy of The Art of the Metaobject Protocol!
      - User23 4y ago
        I too have a significant physical Lisp library, including TAotMOP. I’m also a bit of a curmudgeon and don’t love some of Clojure’s syntactic novelties. But even so I agree that Clojure is a Lisp. Lacking proper tail recursion really isn’t disqualifying. The workflow with CIDER is quite familiar for anyone with Common Lisp experience. I understand there are solid dev plugins for other editors too.
  - didibus 4y ago
    Clojure has access to the same ecosystem as C# since it runs on the CLR and can use .Net libraries and frameworks. It can also have access to the whole Java ecosystem or JavaScript ecosystem. Funny enough, it can also use most Python libraries. And if you're willing to go less official, it also can be used to leverage Erlang's ecosystem and recently Dart and Flutter. Unless you meant something different than being able to leverage libraries, frameworks and some of the tooling?
igouy 4y ago
We had a previous discussion, and my impression was tools don't matter when — "Yeah, there were a lot of side channels for sharing code that made merging things more difficult than they could have been. Poor discipline when devs were in a mad rush." https://news.ycombinator.com/item?id=29926966 https://news.ycombinator.com/item?id=29926966 https://news.ycombinator.com/item?id=29917476 https://news.ycombinator.com/item?id=29917476

neilv 4y ago

When I used ParcPlace Objectworks Smalltalk 4.1. and then VisualWorks Smalltalk in the early '90s, you'd use a menu item to write a human-readable ASCII serialization of some part of the system (not changelog) to the host filesystem. And it'd be diffable and mergeable and loadable. Doing Git with just that seems only a little different than what we'd do with a collection of source files today in some other language, including branches and merges. At the same time, one commercial site I worked at was doing its SCM for C code using kludge scripts over SCCS to an NFS volume. The next was putting C and C++ into Apollo DSEE and making SPARCstations jump through hoops to use that (because ancient DSEE on some Apollo DN10ks for SCM and CI/CD was better than the state of the art almost everyone else was using) and my advanced R&D group had just gotten DSEE-descendant Atria ClearCase for greenfield work in C++ from our Sun and HP workstations. The next site was using some dumpster fire of `.BAT` scripts over Perforce(?) for Windows NT-dominated C++ development. I'd say VisualWorks Smalltalk's wasn't the problem for team development at the time. The state of practice of everything else was more the problem.

User23 4y ago

> Lisp to me is like a fascinating fossil. Evidently you have some experience with Smalltalk, but what makes you say that about Lisp? Also which Lisp exactly do you have in mind? To me the Lisp family of languages is more like Classical music: it doesn’t satisfy some modern sensibilities, but it has a timeless elegance and will be around long after the latest fad is gone.

smackeyacky 4y ago
It's a personal opinion more than anything. I see Clojure getting attention but it isn't going to replace Node.js or .NET any time soon. The major difference being the ecosystem built around something like C# is miles ahead of anything available for even Clojure. Some people might think that's an advantage, but for people like me whose job is to be pragmatic and "git er dun" it's a major impediment. Hence, lisp has become a kind of toy from a golden age. I find myself reaching for C# or Python for experiments. I have dabbled in lisp occasionally over the years but never found Clojure very compelling.
- armitron 4y ago
  You come across as someone with minimal -if any- experience with Lisp, to be making some of the generalizations and grandiose proclamations that you do. Also, lots of people don't consider Clojure a Lisp.
  - shaunxcode 4y ago
    I, for one, consider Clojure a lisp. And I have a physical copy of The Art of the Metaobject Protocol!
    - User23 4y ago
      I too have a significant physical Lisp library, including TAotMOP. I’m also a bit of a curmudgeon and don’t love some of Clojure’s syntactic novelties. But even so I agree that Clojure is a Lisp. Lacking proper tail recursion really isn’t disqualifying. The workflow with CIDER is quite familiar for anyone with Common Lisp experience. I understand there are solid dev plugins for other editors too.
- didibus 4y ago
  Clojure has access to the same ecosystem as C# since it runs on the CLR and can use .Net libraries and frameworks. It can also have access to the whole Java ecosystem or JavaScript ecosystem. Funny enough, it can also use most Python libraries. And if you're willing to go less official, it also can be used to leverage Erlang's ecosystem and recently Dart and Flutter. Unless you meant something different than being able to leverage libraries, frameworks and some of the tooling?

igouy 4y ago

We had a previous discussion, and my impression was tools don't matter when — "Yeah, there were a lot of side channels for sharing code that made merging things more difficult than they could have been. Poor discipline when devs were in a mad rush." https://news.ycombinator.com/item?id=29926966 https://news.ycombinator.com/item?id=29926966 https://news.ycombinator.com/item?id=29917476 https://news.ycombinator.com/item?id=29917476