On Wednesday, 3 January 2018 at 11:13:04 UTC, Joakim wrote:
Not necessarily, it all depends if thinking you're the best
leads to taking your eye off the ball of improving and
acknowledging your problems, which I see little indication of
here.
Well, if a language is used for a narrow set of application areas
then one might be able to have a deep understanding of what the
challenges are.
In general I think it is difficult to understand what challenges
people have in areas one have little familiarity with. I've seen
this time and time again in discussions about memory management.
I think both Rust and D suffers a bit from this. And likewise, I
think C++ designers are making a mistake by presuming that C++
can become a competitive high level language.
So it is a general challenge in language design, I think.
Agreed with much of this: they may be better at various things,
but those things don't matter much of the time.
Yes, I don't think any programmers are "best", some people are
not at all suited for programming or lack some general knowledge,
but otherwise I think we only have good programmers that are
"best" in some very narrow domains.
And who do you know who does this? While I myself have
espoused the idea of the best tool for the job in this forum,
realistically, other than a small handful of coders, when does
that ever happen?
I don't know how many… But if you have a good understanding of a
language like Java and C/machine language, and also have the
equivalent of a bachelor in comp sci, then I think you should be
able to pick up just about any language in relatively short time
(except C++ where the know-how is less accessible for various
reasons).
Anyway, it is my impression that many C/C++ programmers also know
Python and also have a good understanding of basic functional
programming.
I recently read some article linked off proggit that stated the
reality much better: programmers learn a language that suits
them, then use it everywhere they can.
Well. Take an iOS programmer. She/he would start out with
Objective-C, which requires understanding of C. Then maybe you
also need to interface with C++ in order to use some library.
Then you switch over to Swift… Then you need to port the app to
Android and have to pick up some Java. Then somebody want to turn
it into a webapp and you pick up TypeScript… Then someone needs
interfacing with C# for a web-service and you pick up a bit of
that…
As long as you are interfacing with other systems you often
achieve more by learning enough to use something written in
another language than by picking a suboptimal solution that use
your favourite language.
But sure, if I need to hack together something I would usually
think about using Python first, mostly because it is so mallable
for smaller tasks. Not really because it is my preferred
language. I don't really like dynamic typing in principle, but it
is productive for smaller tasks and prototyping.
Given how much effort it takes to know a language platform
well, not only the language itself but all the libraries and
their bottlenecks, and most programmers' limited motivation to
pick up new tech, that is the only approach that makes sense
for the vast majority.
Well, but libraries and frameworks are unfortunately not
permanent. They are shifting relatively fast. Heck, even the Java
standard library contains many things that you don't want to use,
because there is something better in there.
So if you start on a new project there is often a more productive
framework you could go with.
And that might require adopting a new language as well.
This is of course good for new languages. If this was not the
case then it would be near impossible for new languages to
establish themselves.
But it can also be taken as a sign that we don't have the
languages and tooling that enable writing really good timeless
libraries and frameworks.
Maybe that will change in the future, I guess we now are reaching
a point where neither CPU or memory are the limiting factor for
most mundane applications. So maybe that will cause a more stable
infrastructure to emerge… but probably not in our lifetime. I
think we still have a long way to go in even simple areas such as
GUI frameworks.
Yes, but if you're only hyped because you were stowed away on a
popular platform, ie javascript in the browser, or are easy to
learn, Go from what I hear, then the technical limitations of
the language put a ceiling on how high you can go. You'll get
to that ceiling faster, but then you're stuck there.
I perceived that there was a lot of hype around Python 15 years
ago or so. Now, universities are replacing Java with Python as
the introduction language and Python is also becoming the defacto
language for scientific programming. Python is basically getting
critical mass and is now managing to take on Matlab and perhaps
to some extent even C++/Fortran.
There is a loooong road for languages like Rust, D and Julia… All
those scientific simulation frameworks creates are rather heavy
critical mass. That is very difficult to move around (Matlab was
for a long time dominant).
The only time where it is an advantage to be small is when
your language design is changing. Once the language design is
stable there is only disadvantages in not having critical mass.
And since when has the D language design been stable? ;)
Good point… Critical mass might be more damaging that good.
And who's to say D doesn't have critical mass? I'd say
100-200k users (my math based on the chart below: 2k
downloads/day of dmd X 60 days between major versions + ldc/gdc
and external downloads) is a significant market:
http://erdani.com/d/downloads.daily.png
I don't know what to make out of the download metric. It would be
easier to grasp if it was broken down into regional downloads and
if it isn't already, filtered by unique IPs.
It's not hyped or popular, but you can leverage that base to
get bigger, particularly since you didn't sell out and
specialize to get that base in the first place.
Well, but nobody picks a language because it is a good language
for building libraries. They might avoid a language if it is bad
at that, but for a single application you often don't need
generic programming.
When focusing on a niche you have an easier sell for the
specifics of a project. Being a bit better than Rust at this, Go
and that and C++ an this and that, isn't given as much weight as
"hands down most productive solution for Y". And being the most
productive goes beyond language and even libraries, it also
includes knowhow and online tutorials for that narrow area.
