4 ms·

3) Tooling, ecosystem, and library availablity. Picking language X over Y is unwise if it means spending a bunch of time writing the libraries you need, even if

3) Tooling, ecosystem, and library availablity. Picking language X over Y is unwise if it means spending a bunch of time writing the libraries you need, even if it's ultimately more expressive.

Keyframe 8y ago
This, turns out, is ultimately the most important thing amongst most important things. I've invested quite a lot of effort and time in D, back when D1 was around and D2 was a newsgroup post. D1 was everything I wanted out of better C, while d2 looked like it ought to be a better c++. Two years into heavy D programming, d2 vs d1+tango vs phobos aside, most of my time was spent in hunting for things or re-inventing things for weeks which I could've got in minutes with more popular language. Now that I'm older and hopefully wiser, I just go for my standard c toolbelt or, more often, python and be done with whatever I wanted to do without 'the hunt' (often for unmaintened things or things out of my knowledge scope - so I can't even re-implement). With all that said... Lisp' siren call is still out there, and experience tells me it will be the same. (As it was once before)
- earenndil 8y ago
  With the existence of d++[1], you can essentially use any existing c or c++ library by simply including its header file. 1: https://github.com/atilaneves/dpp https://github.com/atilaneves/dpp
  - Keyframe 8y ago
    While interesting, glancing through readme/limitations just furthers my (view)point based on experience. Since then, I do by and large dive into new languages but don't use them. What I do is bring back home some of the practices which I think are of benefit to me.
walshemj 8y ago
Exactly that's why for CFD Fortran still has so many advantages.
rhacker 8y ago
This is definitely key - one startup I worked for was messing around with live voice capture and processing, voice recognition, etc.. by and large the libraries we had access to that could help do tiny manipulations, cutting, processing of the waveform data was primarily C. We wrote most of our code in C++ because we could directly call C functions and use header files directly. This was 15 years ago, but I honestly don't know what language I would use today. It's funny but sometimes binary data handling isn't a particular language's strong suit simply because they don't have the primitives to handle it, or if they do, the APIs to handle them are awkward or unnecessarily verbose. It's kinda neat that in C/C++ you can take a 1MB byte buffer and pass it to a function starting at 30% in. In other languages its like you have to pass in the whole thing and another parameter to tell it where to start. I get that's why C/C++ is in the situation it's in (security - but that's why I don't use C/C++ to handle web requests), but sometimes tasks need that.
- pjmlp 8y ago
  That is how I migrated from Turbo Pascal to C++, around 1994, only touching C when required to do so. Could make use of a saner type system, nice frameworks (Turbo Vision, OWL), while being able to painless create safe wrappers around C libraries.

3) Tooling, ecosystem, and library availablity. Picking language X over Y is unwise if it means spending a bunch of time writing the libraries you need, even if it's ultimately more expressive.

Keyframe 8y ago

This, turns out, is ultimately the most important thing amongst most important things. I've invested quite a lot of effort and time in D, back when D1 was around and D2 was a newsgroup post. D1 was everything I wanted out of better C, while d2 looked like it ought to be a better c++. Two years into heavy D programming, d2 vs d1+tango vs phobos aside, most of my time was spent in hunting for things or re-inventing things for weeks which I could've got in minutes with more popular language. Now that I'm older and hopefully wiser, I just go for my standard c toolbelt or, more often, python and be done with whatever I wanted to do without 'the hunt' (often for unmaintened things or things out of my knowledge scope - so I can't even re-implement). With all that said... Lisp' siren call is still out there, and experience tells me it will be the same. (As it was once before)

earenndil 8y ago
With the existence of d++[1], you can essentially use any existing c or c++ library by simply including its header file. 1: https://github.com/atilaneves/dpp https://github.com/atilaneves/dpp
- Keyframe 8y ago
  While interesting, glancing through readme/limitations just furthers my (view)point based on experience. Since then, I do by and large dive into new languages but don't use them. What I do is bring back home some of the practices which I think are of benefit to me.

walshemj 8y ago

Exactly that's why for CFD Fortran still has so many advantages.

rhacker 8y ago

This is definitely key - one startup I worked for was messing around with live voice capture and processing, voice recognition, etc.. by and large the libraries we had access to that could help do tiny manipulations, cutting, processing of the waveform data was primarily C. We wrote most of our code in C++ because we could directly call C functions and use header files directly. This was 15 years ago, but I honestly don't know what language I would use today. It's funny but sometimes binary data handling isn't a particular language's strong suit simply because they don't have the primitives to handle it, or if they do, the APIs to handle them are awkward or unnecessarily verbose. It's kinda neat that in C/C++ you can take a 1MB byte buffer and pass it to a function starting at 30% in. In other languages its like you have to pass in the whole thing and another parameter to tell it where to start. I get that's why C/C++ is in the situation it's in (security - but that's why I don't use C/C++ to handle web requests), but sometimes tasks need that.

pjmlp 8y ago
That is how I migrated from Turbo Pascal to C++, around 1994, only touching C when required to do so. Could make use of a saner type system, nice frameworks (Turbo Vision, OWL), while being able to painless create safe wrappers around C libraries.