4 ms·

This is really interesting. What kind of metrics is the culture focused on? How were they established. Can you think of examples when critical/deliberate decisi

by senex 9y ago

This is really interesting. What kind of metrics is the culture focused on? How were they established. Can you think of examples when critical/deliberate decisions were made to pursue the integrity of the culture (rather than shifting or broadening focus)? Has cultural orientation or measurements changed over time? How and why? Are there other examples of cultures focused on particular metrics that have flourished? Or faded away? Super curious...

urs2102 9y ago
So there are a number of examples, but Bjarne used to stress 'compatibility' for example. It was a really important idea for him, that despite the really clean and smaller language that he could have developed, it was very important for him to have tighter compatibility with C. In many ways, he discussed how he hasn't built a 'perfect language', and that as languages operate as tools, it's very important to be focused and decide what matters over what doesn't. Sure you could have a prettier language, but as programmers there is a cost to everything and sometimes we are so eager to see the benefits in any new tool, it's easy to forget to measure the costs (he also really, really enjoyed having us benchmark things to see the cost in using x method over y method). Making it explicitly clear what you intend to focus on, and setting a standard for not just yourself, but your community encourages the language to grow in a way that it remains useful and sustainable. He mentioned that if he built out this tighter/cleaner language, it's also possible that the language would have failed to generate any traction at all. I'm not entirely sure of cultures that have flourished or faded particular ideas, but if you look at how despite newer languages are constantly taking old ideas from Lisp, how come Lisp didn't take off (and I say this as a true fan of Lisp)? Again, I'm totally hypothesizing, but it may have to do with compatibility. You can say that Lisp's syntax (or lack thereof) is really important to not just how macros are developed, but for Lisp programmers to have a language that evolves. Yet at the same time, Lisp's greatest strength is often its biggest weakness. You can't really standardize something that evolves all the time, and as such, can't really have compatability. How do I build a library for a language that despite becoming more powerful for the particular purpose I started using it for, looks nothing like anything else out there? I think his main point tended to be, pick things that matter to you: metrics that matter to you, ideas that matter to you, a mission that matters to you and just really work on that. It's easy to get distracted and just add features "just because", but make sure they conform to the metrics you set forth for yourself.
- pjmlp 9y ago
  He was quite right, this is what attracted me to C++ after Turbo Pascal, in spite of disliking C. I could have the type safety of Turbo Pascal, its scope of language features and spend less time writing my own FFI wrappers to the OS APIs, that were adopting C as their new systems language. Of course to achieve that safety like level, I still had to write my own wrapper classes, but it was less effort than full blown FFI code in languages that have completely difference concepts. EDIT: Typo, was -> as
- lispm 9y ago
  > You can't really standardize something that evolves all the time You standardize the meta-level and then use best practices. There are many possibilities to extend a language using macros, but actual macro mechanisms may favor a few (for example because some macros are straight forward, where others are more difficult to implement). Thus one now has to learn: how the macro mechanism works, what is the best way to write macros, how to debug macros, ... Working on and with this meta-level is more difficult. > How do I build a library for a language that despite becoming more powerful for the particular purpose I started using it for, looks nothing like anything else out there? Usually one would build macros in similar ways. There are some domain-independent principles.
  - urs2102 9y ago
    Absolutely! Oh, don’t get me wrong (again, Common Lisp/Scheme were instrumental in getting me into programming so you’re preaching to the choir), but I guess the point I was trying to make is that there is a real difference between the Lisp approach to standardization and of course C++. Apologies for not being more clear. There are definite ways to standardize a Lisp, I mean look at all the awesome work Rich Hickey as done on building out Clojure. I just feel that the Lisp (huge generalization incoming) may not care for standardization in the same way Bjarne does when developing C++. The point I was trying to make (let’s take an example Bjarne cared about that isn’t compatability) is that people in different language communities care about different things. I think it’s fair to say that Ruby developers don’t think about speed as much as people working on C++. It’s not that they don’t care, but ‘programmer happiness’ in the way Matz thinks about Ruby (having an ‘unless’ keyword for example) is more important to Matz than speed. Again, it would be crazy to say Matz doesn’t care about speed, but he, like Bjarne, obviously prioritizes some things over others. For a college student taking the class, it may seem obvious (“well of course you should build a language focused on certain metrics”), but it’s easier said than done. I remember working on a compiler my junior year where I all I wanted to do was continually add features to my language. Often the problem with the language was with the goals I’d set forth and addressing the problem I was trying to solve, not simply adding more features. Focus over features is the idea I think Bjarne got across super well.

by senex 9y ago

urs2102 9y ago

So there are a number of examples, but Bjarne used to stress 'compatibility' for example. It was a really important idea for him, that despite the really clean and smaller language that he could have developed, it was very important for him to have tighter compatibility with C. In many ways, he discussed how he hasn't built a 'perfect language', and that as languages operate as tools, it's very important to be focused and decide what matters over what doesn't. Sure you could have a prettier language, but as programmers there is a cost to everything and sometimes we are so eager to see the benefits in any new tool, it's easy to forget to measure the costs (he also really, really enjoyed having us benchmark things to see the cost in using x method over y method). Making it explicitly clear what you intend to focus on, and setting a standard for not just yourself, but your community encourages the language to grow in a way that it remains useful and sustainable. He mentioned that if he built out this tighter/cleaner language, it's also possible that the language would have failed to generate any traction at all. I'm not entirely sure of cultures that have flourished or faded particular ideas, but if you look at how despite newer languages are constantly taking old ideas from Lisp, how come Lisp didn't take off (and I say this as a true fan of Lisp)? Again, I'm totally hypothesizing, but it may have to do with compatibility. You can say that Lisp's syntax (or lack thereof) is really important to not just how macros are developed, but for Lisp programmers to have a language that evolves. Yet at the same time, Lisp's greatest strength is often its biggest weakness. You can't really standardize something that evolves all the time, and as such, can't really have compatability. How do I build a library for a language that despite becoming more powerful for the particular purpose I started using it for, looks nothing like anything else out there? I think his main point tended to be, pick things that matter to you: metrics that matter to you, ideas that matter to you, a mission that matters to you and just really work on that. It's easy to get distracted and just add features "just because", but make sure they conform to the metrics you set forth for yourself.

pjmlp 9y ago
He was quite right, this is what attracted me to C++ after Turbo Pascal, in spite of disliking C. I could have the type safety of Turbo Pascal, its scope of language features and spend less time writing my own FFI wrappers to the OS APIs, that were adopting C as their new systems language. Of course to achieve that safety like level, I still had to write my own wrapper classes, but it was less effort than full blown FFI code in languages that have completely difference concepts. EDIT: Typo, was -> as
lispm 9y ago
> You can't really standardize something that evolves all the time You standardize the meta-level and then use best practices. There are many possibilities to extend a language using macros, but actual macro mechanisms may favor a few (for example because some macros are straight forward, where others are more difficult to implement). Thus one now has to learn: how the macro mechanism works, what is the best way to write macros, how to debug macros, ... Working on and with this meta-level is more difficult. > How do I build a library for a language that despite becoming more powerful for the particular purpose I started using it for, looks nothing like anything else out there? Usually one would build macros in similar ways. There are some domain-independent principles.
- urs2102 9y ago
  Absolutely! Oh, don’t get me wrong (again, Common Lisp/Scheme were instrumental in getting me into programming so you’re preaching to the choir), but I guess the point I was trying to make is that there is a real difference between the Lisp approach to standardization and of course C++. Apologies for not being more clear. There are definite ways to standardize a Lisp, I mean look at all the awesome work Rich Hickey as done on building out Clojure. I just feel that the Lisp (huge generalization incoming) may not care for standardization in the same way Bjarne does when developing C++. The point I was trying to make (let’s take an example Bjarne cared about that isn’t compatability) is that people in different language communities care about different things. I think it’s fair to say that Ruby developers don’t think about speed as much as people working on C++. It’s not that they don’t care, but ‘programmer happiness’ in the way Matz thinks about Ruby (having an ‘unless’ keyword for example) is more important to Matz than speed. Again, it would be crazy to say Matz doesn’t care about speed, but he, like Bjarne, obviously prioritizes some things over others. For a college student taking the class, it may seem obvious (“well of course you should build a language focused on certain metrics”), but it’s easier said than done. I remember working on a compiler my junior year where I all I wanted to do was continually add features to my language. Often the problem with the language was with the goals I’d set forth and addressing the problem I was trying to solve, not simply adding more features. Focus over features is the idea I think Bjarne got across super well.