Several languages seem to share this curse. You do see companies advertise it on language conferences or websites: Jane Street for OCaml, Remedy Entertainment for D-lang, Naughty Dog and ITA for Common Lisp. But you are often left wondering if it is the tip if the iceberg, or an accurate reflection of industry use. In the case of CL, you see multiple commercial implementations still being supported, indicating much more use than one would suspect from grepping github projects.
A pattern I seem to observe is that if the program/framework/platform grows large and successful enough, the company gets acquired for its tech and everything gets rewritten in some more 'industry standard' language.
edit: As pointed out, Jane Street advertises its OCaml use, not Haskell. Oops!
>A pattern I seem to observe is that if the program/framework/platform grows large and successful enough, the company gets acquired for its tech and everything gets rewritten in some more 'industry standard' language.
I wonder if that happened for ITA's software after ITA was acquired by Google (for some hundreds of millions, IIRC).
I read somewhere that Paul Graham's ViaWeb, which was written in mainly Lisp (or at least some key parts were), was later rewritten in some other language, maybe C++, like the pattern you observe.
Probably it's not that easy to replace Lisp for something else at Google, since it implements a relatively complex search engine core. Thus it's still used. I guess they WOULD be happy to replace it, since Lisp is otherwise not used much at Google, AFAIK. ITA/Google also developed another complex application using Lisp (a reservation system for airlines, initially for Air Canada), but that wasn't successful in the market.
At Viaweb Lisp was used for an early web store maker (enables people to have their own webshop) implementation.
> company gets acquired for its tech
Actually companies get bought for a business model, customers and some amount of tech. Reimplementing earlier approaches, even multiple times, even multiple times with different technologies, seems to be normal in the web business.
>Probably it's not that easy to replace Lisp for something else at Google, since it implements a relatively complex search engine core. Thus it's still used.
Thanks, makes sense.
>At Viaweb Lisp was used for an early web store maker (enables people to have their own webshop) implementation.
Yes, I had read PG's article about it ("Beating the Averages"). IIRC the templating language they used in ViaWeb, which allowed customers to customize their stores, was a killer feature, and relied heavily on some Lisp language feature, maybe macros.
why is it in a company's best interest to not evangelize the publicly-available tools it uses?
Microsoft/Amazon/Google are paying $$$ to increase availability of AI/machine learning education, because they want a knowledge pool to hire from. Wouldn't this be the same with languages?
Two have told me they did so because D enabled them to write faster code than their competitors, and they were in a line of business where faster code meant making more money.
One reason D code is faster is array slicing, where you can refer to a subsection of an array. This pays off for things like strings. Consider the string:
s = "/root/me/file.ext";
I want to extract the "file" as a string. In C/C++, because strings are 0-terminated, I have a cache hit, allocate 5 bytes and copy 5 characters and install a 0. In D,
name = s[9 .. 13];
I have no cache hit, add 9 to a pointer, copy 5 to the length.
(A slice is equivalent to a (length, pointer) pair.)
>why is it in a company's best interest to not evangelize the publicly-available tools it uses?
Because they want people that are good with the tool, not people that crash-coursed/bootcamped their way into what they are told is a marketable skill.
The difference being with Python you gained in prototyping speed but were losing (at least at the time) on execution speed, whereas in D you get rapid prototyping while keeping very high efficiency.
Good point. But that is partly due to the design of Python, it being a highly dynamic language. I don't want to get into any flame wars, but I'd hazard a guess that Python is somewhat more dynamic in nature than D (I know some D, and Python well), and that at the least, some of the things one can do in Python, would require a lot more knowledge and skill (with D) and acrobatics or contortions (speaking loosely) to do in D. (It would be good to be proven wrong on this, though :) This is not a criticism of D, I really like the language, and am aware of its power. Check out these two posts about D by Dmitry Popov (lead developer and Director), on the Infognition blog:
In fact, here are some posts I've written that show how to write some kinds of basic apps for various purposes in D, that I posted about on HN just recently:
Congrats for Weka.IO. They managed to pull it through after the CEO visited the DConf and asked for help.
D is a brilliant language. I got drawn into D by this article[1]. I've used D to replace some of the test tools where Java/Python were used. GC is a friend in such cases. I could've written them in C++ as well, but Phobos wins over STL hands down!
Initially the "solution" test application for one of our REST services was written in Java. It covered the functional, performance and longevity tests. The REST service itself was written in C++. Ultimately the customers reported that under heavy load the response time of the REST service is too long (> 400 ms) and we fixed the code as well. But during tests we were unable to really load the application to the fullest. 48 cores & 48 threads in Java and we still couldn't overload the REST service. We had no way to prove that our fix actually worked. Ultimately, we rewrote the test app in D and boom, we were finally able to achieve the load that customers created in their production env - both in terms of response times and throughput. I could've written it in C++. But D's std.parallelism + template mixin is a boon, thanks to David Simcha. Based on our tests, the D test app was 20 times faster than the Java equivalent (written by one of the finest and the expert).
Sure, there is a lot of visual noise due to @nogc, etc, etc. But beneath that there is a beautiful and readable language that's waiting to unfold, if and only if the D authors realize that they stop the feature creep and revert to sane defaults.
On the other hand, I started to convert the REST service from C++ to D last year and it didn't go well. Blame me! There are _very_ rough edges in D as well that are result of over engineering. One such thing is the const'ness in D. It make it impossible to use const, ever, by library authors. I don't care to go and fight in D forum. Manu has already screamed many a times. Lately I found that one of the reasons for poor performance of my D port was also because of auto-decoding! Duh! It was not even GC. (The default should be fast, isn't it?). I spent a considerable amount of time for this port and eventually it failed to meet the performance vs maintainability trade-off. C++ is getting better year by year, at least every 5 years :-). std::vector, std::map, etc are safe for concurrent reads (at least on POSIX). std::vector has erase with iterator. Phobo's std.array doesn't have an equivalent features, albeit it is much more readable than STL.
FWIW, D doesn't deserve the negative publicity that it usually gets. It's a fantastic language. Try it and if you like it, enjoy using it for the right use cases. After all choose the right tool for the job at hand.
The difference between const in D and const in C++ is that D's const is transitive, and C++'s is not.
Transitive const is necessary for things like pure functions. It's more difficult to use because the compiler really, really means it. But when it's there, you (the user) knows that function is not modifying the const data structure, not no-how, not no-way.
A pattern I seem to observe is that if the program/framework/platform grows large and successful enough, the company gets acquired for its tech and everything gets rewritten in some more 'industry standard' language.
edit: As pointed out, Jane Street advertises its OCaml use, not Haskell. Oops!