7 ms·

Might be a little off topic, but what’s with the ”written in” obsession? From my perspective it’s so irrelevant compared to well tested, design, architectured,

Might be a little off topic, but what’s with the ”written in” obsession? From my perspective it’s so irrelevant compared to well tested, design, architectured, community engagement, track record, performance and usability. Call me crazy, but how does the language you do this in become relevant? As a reference perhaps? Only the best of intentions here, have i missed a paticular pov that makes this extra relevant?

Phlogistique 6y ago
It's relevant: * For projects where one of the main purposes is for the author of the project to learn said language * For projects which expose an API in their implementation language. In the case of an implementation of a programming language, they might offer embeddability in the host language, or a foreign function interface with the host language.
- moring 6y ago
  Why do we consider it normal that APIs are exposed for the implementation language of a project (library, interpreter, application, whatever) but usually not other languages? Is there any evidence that the "user" of an API is likely to prefer the same language that was used for the original thing? (BTW this does not seem to be the case for networked APIs such as REST services).
  - richardwhiuk 6y ago
    Thunking across FFI often takes a lot of work to make it ergonomic.
  - mumblemumble 6y ago
    The only really stable, standardized, well-supported ABI out there is the C ABI. Communicating across it is a chore. On the side of the language publishing the API, you need to write a C-friendly façade that translates everything your language has that C doesn't into a much more Spartan semantic space. You'll be losing or having to re-implement pretty much everything you like about that language: any sort of dynamic dispatch, memory management semantics, exceptions, etc. And then, on the client language side, you probably want to write another façade in order to, to the extent that it's feasible, restore all those sorts of niceties. Direct FFIs are possible, but generally don't happen except in exceptional cases because of the cost involved in writing a new FFI (and accompanying set of gotchas) for every possible language whose packages you might want to consume. The best and worst thing about the C ABI is that it's pretty much the least common denominator. Even in platforms like Java and .NET that theoretically smooth over these problems, we find that it never works out that well in practice. Scala and F# users end up having to write compatibility layers in order to preset Java and C# friendly APIs, and they end up writing their own versions of just about every possible library in order to have packages that don't feel awkward to use in their language of choice. The only real exception I know of to that pattern on the JVM or the CLR is between C# and Visual Basic, and that is only because Microsoft was very careful to ensure that the two languages' semantics were similar enough to virtually guarantee no cross-language friction.
    - deleted 6y ago
      [deleted]
    - pjmlp 6y ago
      COM/UWP are doing just fine on Windows world.
      - mumblemumble 6y ago
        UWP in particular is very nice. But I would argue that, for most of us, the "W" stands for "not well-supported."
- Jumziey 6y ago
  I agree, "machine learning framework written in <lang>" is relevant, not sure i agree about an interpreter though :p
rileymat2 6y ago
I am surely an outlier being a developer, but I like to know the project language without clicking as an overview of what people are doing. I'd suggest that in many forums it is irrelevant to most and should be left off, but I suspect HN is not a representative sample of the general public and many may share my sentiment.
- Jumziey 6y ago
  Yeah, but why? Is it a feeling? Is it because it's not relevant if you can't immediately read the code since it's not a language you usually read/write in? Once again just curious :)
  - rileymat2 6y ago
    With HN, from the comments I get an idea of whether or not the language as a tool fits the solution in a unique way, or if it is a novelty. So even if I cannot read the code, I can mentally get an idea that tool X is a good fit for problem Y should it ever come up for me.
coliveira 6y ago
This demonstrates a modern distortion in software engineering where people are trained to hate other languages they don't use and reinvent the wheel in each new language. Each new language that is introduced seems to reinforce this incorrect perception and it seems that we can barely do anything else than reinventing the same old, well-tested libraries in the next "language du jour".
- pjmlp 6y ago
  Modern? Nope, language flamewars were pretty much alive on BBSs and USENET. I have had my share against C on comp.lang.c and comp.lang.c.moderated.
augustk 6y ago
Sometimes the name of the implementation language even creeps into the project name, like with the MIDI sequencer Jazz++.
swiftcoder 6y ago
it's relevant in this case because most simple Lisp-like interpreters are written in... Lisp (or at least one of the many other Lisp-like languages). Interpreting a simple lisp-like in lisp is borderline trivial. Interpreting a simple lisp-like in an imperative language demonstrates a significantly more fundamental understanding of how lisp-like languages work.
wott 6y ago
> Might be a little off topic, but what’s with the ”written in” obsession? From my perspective it’s so irrelevant compared to well tested, design, architectured, community engagement, track record, performance and usability. As far as I am concerned there is one aspect where I think it is relevant for me, as I compile all software that runs on my machine. If it written in C or in C++, there are good chances that I won't need to compile an horrible chain of dependencies (or most likely, try and fail at compile that chain). That matters to me, because I try a lot of alternative/niche/toy languages, and if I consider those published within, say, the last ten years, half of them won't even compile. It is a disaster. If it is written in shell + C, I can fix a couple errors easily (if there are more I give up because there is no point in wasting my time on something that claims to be next programming marvel and yet is itself programmed like shit). People want to be fancy and pick up toolchains that are not battle-tested like Autotools+C or CMake+C++, and that's the recipe for pain. For example, today I tried to compile two languages written in Ada, and I had to give up. A mess. Each time I tried to build an Ada project which wasn't mine, it has been horrible. That's antinomic to the image of Ada (clean and strict to the point of being stiff) but that's my repeated experience with building. I am not even talking about the anti-feature which is compilers which are written in the very language they aim to compile and do not even provide a bootstrapping minimal compiler written in C or similarly fundamental and widespread language. They're generally very proud of their accomplishment :-/ So yes, a project in C (or C++) offers the best chances of success (for building, which is the point I developed here). Also, considering toy language, I often want to make a dirty hack to add a missing features. If it is written, say, in Haskell, there is zero chance I can do it. Good old imperative languages like C, Python, Pascal, I have a chance and I have already done it. There is also the case of all the languages built over the JVM. There are really many. But even when they look good to me, they are limited by the opinionated choices of the JVM, and I don't wanna undergo the multiple programming neuroses of Gosling. Also anything Java based has always been terribly, awfully, painfully, excruciatingly slow on any of my machines; I suppose it not an universal experience, but it has always been mine. ------ > compared to well tested, design, architectured, community engagement, track record, performance and usability. To each is own: I care about well tested, usability, and depending on the intended use, performance. I also care a lot about proper exhaustive documentation, which is missing from your list and from most programming languages projects. But I don't give a damn about its design and architecture, what matters to me is the external features, not the internals. Language designers care way too much about the internals and neglect the outside, which is what matters to the end user. I don't care if it make your parser more complicated, it if makes your grammar irregular, if you need more passes, if you need to dirty your hands with context; I want that source code using your language flows, for writing and for reading. Community? I don't really care, and I have seen it being detrimental to many projects, which lose their compass by wanting to incorporate every feature request and following the mood of the year; I'd rather they were developed between closed doors and only published when they reach beta status, to maintain consistency, instead of jumping from an unpolished feature to the next. I am aware that's totally against the current trend, where people publish repositories with a README.md before writing the first line of code or documentation :-)
nn3 6y ago
I like it actually as a mental filter. If the language is the main defining quality it usually means the project is nowhere near production ready, and can be safely ignored for now.
zelphirkalt 6y ago
It becomes important for the trustworthiness of the underlying implementation. Some need way more bulletproofing than others.

Phlogistique 6y ago

It's relevant: * For projects where one of the main purposes is for the author of the project to learn said language * For projects which expose an API in their implementation language. In the case of an implementation of a programming language, they might offer embeddability in the host language, or a foreign function interface with the host language.

moring 6y ago
Why do we consider it normal that APIs are exposed for the implementation language of a project (library, interpreter, application, whatever) but usually not other languages? Is there any evidence that the "user" of an API is likely to prefer the same language that was used for the original thing? (BTW this does not seem to be the case for networked APIs such as REST services).
- richardwhiuk 6y ago
  Thunking across FFI often takes a lot of work to make it ergonomic.
- mumblemumble 6y ago
  The only really stable, standardized, well-supported ABI out there is the C ABI. Communicating across it is a chore. On the side of the language publishing the API, you need to write a C-friendly façade that translates everything your language has that C doesn't into a much more Spartan semantic space. You'll be losing or having to re-implement pretty much everything you like about that language: any sort of dynamic dispatch, memory management semantics, exceptions, etc. And then, on the client language side, you probably want to write another façade in order to, to the extent that it's feasible, restore all those sorts of niceties. Direct FFIs are possible, but generally don't happen except in exceptional cases because of the cost involved in writing a new FFI (and accompanying set of gotchas) for every possible language whose packages you might want to consume. The best and worst thing about the C ABI is that it's pretty much the least common denominator. Even in platforms like Java and .NET that theoretically smooth over these problems, we find that it never works out that well in practice. Scala and F# users end up having to write compatibility layers in order to preset Java and C# friendly APIs, and they end up writing their own versions of just about every possible library in order to have packages that don't feel awkward to use in their language of choice. The only real exception I know of to that pattern on the JVM or the CLR is between C# and Visual Basic, and that is only because Microsoft was very careful to ensure that the two languages' semantics were similar enough to virtually guarantee no cross-language friction.
  - deleted 6y ago
    [deleted]
  - pjmlp 6y ago
    COM/UWP are doing just fine on Windows world.
    - mumblemumble 6y ago
      UWP in particular is very nice. But I would argue that, for most of us, the "W" stands for "not well-supported."
Jumziey 6y ago
I agree, "machine learning framework written in <lang>" is relevant, not sure i agree about an interpreter though :p

rileymat2 6y ago

I am surely an outlier being a developer, but I like to know the project language without clicking as an overview of what people are doing. I'd suggest that in many forums it is irrelevant to most and should be left off, but I suspect HN is not a representative sample of the general public and many may share my sentiment.

Jumziey 6y ago
Yeah, but why? Is it a feeling? Is it because it's not relevant if you can't immediately read the code since it's not a language you usually read/write in? Once again just curious :)
- rileymat2 6y ago
  With HN, from the comments I get an idea of whether or not the language as a tool fits the solution in a unique way, or if it is a novelty. So even if I cannot read the code, I can mentally get an idea that tool X is a good fit for problem Y should it ever come up for me.

coliveira 6y ago

This demonstrates a modern distortion in software engineering where people are trained to hate other languages they don't use and reinvent the wheel in each new language. Each new language that is introduced seems to reinforce this incorrect perception and it seems that we can barely do anything else than reinventing the same old, well-tested libraries in the next "language du jour".

pjmlp 6y ago
Modern? Nope, language flamewars were pretty much alive on BBSs and USENET. I have had my share against C on comp.lang.c and comp.lang.c.moderated.

augustk 6y ago

Sometimes the name of the implementation language even creeps into the project name, like with the MIDI sequencer Jazz++.

swiftcoder 6y ago

it's relevant in this case because most simple Lisp-like interpreters are written in... Lisp (or at least one of the many other Lisp-like languages). Interpreting a simple lisp-like in lisp is borderline trivial. Interpreting a simple lisp-like in an imperative language demonstrates a significantly more fundamental understanding of how lisp-like languages work.

wott 6y ago

> Might be a little off topic, but what’s with the ”written in” obsession? From my perspective it’s so irrelevant compared to well tested, design, architectured, community engagement, track record, performance and usability. As far as I am concerned there is one aspect where I think it is relevant for me, as I compile all software that runs on my machine. If it written in C or in C++, there are good chances that I won't need to compile an horrible chain of dependencies (or most likely, try and fail at compile that chain). That matters to me, because I try a lot of alternative/niche/toy languages, and if I consider those published within, say, the last ten years, half of them won't even compile. It is a disaster. If it is written in shell + C, I can fix a couple errors easily (if there are more I give up because there is no point in wasting my time on something that claims to be next programming marvel and yet is itself programmed like shit). People want to be fancy and pick up toolchains that are not battle-tested like Autotools+C or CMake+C++, and that's the recipe for pain. For example, today I tried to compile two languages written in Ada, and I had to give up. A mess. Each time I tried to build an Ada project which wasn't mine, it has been horrible. That's antinomic to the image of Ada (clean and strict to the point of being stiff) but that's my repeated experience with building. I am not even talking about the anti-feature which is compilers which are written in the very language they aim to compile and do not even provide a bootstrapping minimal compiler written in C or similarly fundamental and widespread language. They're generally very proud of their accomplishment :-/ So yes, a project in C (or C++) offers the best chances of success (for building, which is the point I developed here). Also, considering toy language, I often want to make a dirty hack to add a missing features. If it is written, say, in Haskell, there is zero chance I can do it. Good old imperative languages like C, Python, Pascal, I have a chance and I have already done it. There is also the case of all the languages built over the JVM. There are really many. But even when they look good to me, they are limited by the opinionated choices of the JVM, and I don't wanna undergo the multiple programming neuroses of Gosling. Also anything Java based has always been terribly, awfully, painfully, excruciatingly slow on any of my machines; I suppose it not an universal experience, but it has always been mine. ------ > compared to well tested, design, architectured, community engagement, track record, performance and usability. To each is own: I care about well tested, usability, and depending on the intended use, performance. I also care a lot about proper exhaustive documentation, which is missing from your list and from most programming languages projects. But I don't give a damn about its design and architecture, what matters to me is the external features, not the internals. Language designers care way too much about the internals and neglect the outside, which is what matters to the end user. I don't care if it make your parser more complicated, it if makes your grammar irregular, if you need more passes, if you need to dirty your hands with context; I want that source code using your language flows, for writing and for reading. Community? I don't really care, and I have seen it being detrimental to many projects, which lose their compass by wanting to incorporate every feature request and following the mood of the year; I'd rather they were developed between closed doors and only published when they reach beta status, to maintain consistency, instead of jumping from an unpolished feature to the next. I am aware that's totally against the current trend, where people publish repositories with a README.md before writing the first line of code or documentation :-)

nn3 6y ago

I like it actually as a mental filter. If the language is the main defining quality it usually means the project is nowhere near production ready, and can be safely ignored for now.

zelphirkalt 6y ago

It becomes important for the trustworthiness of the underlying implementation. Some need way more bulletproofing than others.