How do you use D?

[Joakim]

On Wednesday, 3 January 2018 at 17:50:01 UTC, Ola Fosheim Grøstad 
wrote:
> On Wednesday, 3 January 2018 at 16:20:48 UTC, Joakim wrote:
>> These languages may all have these problems, but I don't see 
>> the connection to your original point about it not being good 
>> to think you're the best.
>
> Hm?  I tried to say that it is not good to think that you have 
> the best programmers. Or that you are satisfied with only 
> appealing to the best programmers.

Yes, but when I pointed out that it's fine to think you're the 
best as long as you stay focused on bettering the flaws you still 
have, you responded with points about memory management and how 
C++ can't be a "competitive high level language," seemingly 
ignoring the topic at hand.  Good to see you address it below.

> There are some assumptions about "best" in that attitude that 
> isn't healthy for developing an ecosystem.  First of all, it 
> might not be true, maybe the best programmers go elsewhere.  
> Second of all, programmers generally don't start out as "best".
>  And only appealing to experience programmers is not a good 
> long term strategy.

Thinking you're the best doesn't imply that inexperienced 
programmers shouldn't show up, it just means they better think 
they have the ability to someday be similarly good. ;) And when 
you're smaller and trying to take on older languages with many 
more users, you need some identity to rally your much smaller 
group of insurgents: thinking you're the best is as good a 
rallying cry as any other.

Finally, D is hardly pitched as an "expert-only" language, given 
it makes pragmatic choices to use a GC by default and carry 
forward the popular C syntax.  It simply provides many more power 
tools that you can use, if you're so inclined to go farther and 
learn more.

> Anyway, you probably have a lot more great programmers using 
> Javascript than any small language, measured in absolute 
> numbers. And when growing a eco system it is those absolute 
> numbers that matters. It doesn't matter if 99% are not good if 
> the other 1% can grow your infrastructure. And well, right now 
> that means developers can be very productive in that eco system 
> (e.g. TypeScript, Angular, React etc).

What would be better, a million JS programmers with 10k great 
ones who "grow your infrastructure," or 150k D programmers with 
30k great ones doing the same?  Holding everything else 
equivalent proportionally, I'd say the latter.  Of course, a very 
important factor could be how willing the million is to pay for 
better tools, as that will lead to great tools programmers from 
less-popular languages to swarm into JS for the money, but given 
how much of the time all these dev tools are free, particularly 
for JS, that doesn't matter as much.

Another huge factor is that you are fundamentally limited by the 
language, it doesn't matter how many great devs work on speeding 
up a fundamentally slow and inefficient language design, which a 
core team of great programmers wouldn't have put out there in the 
first place. :P

>> More programmers don't have a bachelors in CS than those who 
>> do.  I think you'll find the percentage who regularly use 
>> multiple languages is fairly low, let alone evaluating each 
>> one for each job.
>
> I think it depends on what type of developement we are talking 
> about. But I see a lot of fuzz about fullstack developers. Not 
> sure if that fuzz translates into something at scale, but 
> "full-stack" is at least something that is mentioned frequently.

It's a high percentage without CS bachelors in most subfields of 
programming.  As for "full stack," a meaningless term which I bet 
actually has less CS bachelors than the percentage I gave. ;)

>>> Anyway, it is my impression that many C/C++ programmers also 
>>> know Python and also have a good understanding of basic 
>>> functional programming.
>>
>> So two tools in the toolbox is enough?
>
> Not sure what you mean by that. I meant to say that my 
> impression is that most C/C++ programmers need a higher level 
> language and also are capable of using other paradigms than 
> what C/C++ encourages. Despite C++ being able to express a lot 
> of the same things and also despite C++ being a language where 
> you never really reach a full deep understanding of the 
> language.

It's pretty simple what I mean: you were responding to my point 
that most don't really pick the best tool for the job, but have a 
single language that they try to hammer every nail with.  Saying 
that most C++ programmers also use python implies that having two 
tools that you choose from is enough.  In that case, you're 
basically agreeing with me, despite your previous statements 
otherwise, as I was saying we can't expect most programmers to 
learn more than one tool, ie a single language.

>> Your company is much more likely to bring in somebody with 
>> Java experience to write the Android portion.
>
> Mostly because of the iOS/Android frameworks, not really 
> because of the languages.

That's why I included such knowledge of the needed frameworks in 
knowing a language platform earlier, as realistically it can be 
as important to getting the job done.

> Or rather, the Java language shouldn't be the stumbling block, 
> but both of iOS and Android are rather bloated frameworks that 
> takes time getting into. Which I think it is intentional. Both 
> Apple and Google want developers to be dedicated experts on 
> their platform and seems to deliberately go for changes that 
> prevent cross platform tooling.

Could be, but that changes nothing about the reality that most 
programmers are just going to pick one language and some set of 
frameworks that are commonly used with it.

>> It is unrealistic to expect the vast majority of programmers 
>> to do any more than use one language most of the time.
>
> I don't know. Depends on what kind of development we are 
> talking about.

That is the current reality, it doesn't matter what hypothetical 
kind of development you have in mind.

>> This actually argues for a single language: you're going to 
>> spend a ton of time tracking all those shifting frameworks so 
>> you won't have time for a new language too, but at least you 
>> won't have to learn a new language every time you pick up the 
>> new js framework of the day.
>
> I think there is another way, but it isn't available yet.
>
> Program transliteration and software synthesis should over time 
> be able to offset some of these issues.
>
> Most imperative languages are fairly similar.  Most of the code 
> we write, whether it is in Python, C+ or D would have a fairly 
> similar structure.  In some sections you get something very 
> different, but I don't think that is dominating.

Yes, that is part of the plan with betterC, to make it easy to 
translate C code to D.

>> The ongoing churn may help new languages with new users and 
>> companies, don't think it helps with users who already know a 
>> language well.
>
> I don't know. Seems that many in these forums have done work in 
> Java, Go, Python, Rust and C++.

D users are the exception that prove the rule, the much larger 
majority not using D because they're already entrenched in their 
language.  That's because, unlike Go, D offers many more features 
than other languages, so it particularly appeals to such advanced 
users from other languages.

>> Seems like an oxymoron, tech changes so fast that I don't see 
>> how anything could be timeless, even if you really mean "will 
>> still be the same 20 years from now." ;)
>
> Right, but digital computing is a relatively new invention (and 
> well, even electricity is relatively new ;-).  Over time one 
> would think that something "timeless" would establish itself. 
> But for now we can just say "stable".
>
> There clearly are some frameworks that have been relatively 
> stable. Like matlab. I think that is because matlab has tried 
> to closely model the domain that scientists have been trained 
> in (linear algebra). But it is interesting that Python is 
> making inroads there. That matlab is now perceived as not 
> having good enough abstraction mechanisms, perhaps.
>
> On the other hand, the mathematical field of logic is also 
> relatively new as it is conceptualized today, and some people 
> are exploring paradigms such as probabilistic programming 
> languages and what not… So right, "timeless" is not realistic 
> at the moment as the basic foundation is still quite new and we 
> are still learning how to make computers reason about first 
> order logic… (building automatic theorem provers).

I don't think such stability will ever happen, because unlike 
electricity distribution or other older tech, software is 
infinitely malleable.  We're always going to keep stretching and 
twisting it in new ways, as we get more used to its plasticity.  
We will do a better job of securing and developing it, but we're 
always going to keep changing it.

>> There's always new stuff other than that, eg more limited 
>> mobile hardware over the last decade has returned the tech 
>> market to earlier times, and native languages like Obj-C and 
>> Swift have benefited.
>
> Yeah, as you have pointed out many times, mobile CPUs are 
> quickly catching up at the high end and also to some extent on 
> the middle-end. What remains to be seen is how the mass-market 
> low end picks up.  I think companies like Motorola is pushing 
> the curve at the low/middle phone market as Samsung and Apple 
> have taken the high end.

Sure, so you _could_ now run python on those newly powerful 
mobile CPUs, but Objective-C and Swift have used that decade when 
you _couldn't_ to entrench themselves in that market.  And as 
I've pointed out to you before, they're still much more 
efficient, so until battery tech get much better, you're going to 
want to stick with those natively-compiled languages.

>> Python has done well in those niches, but when is the last 
>> time you saw a popular GUI app written in Python?
>
> Many applications use Python (or Lua or Java or even Visual 
> Basic) to tie the pieces together, including the GUI, but they 
> use engines written in other languages for interfacing with the 
> OS.

Which of those python-glued GUI apps has become popular?  That 
was the question: I can find toy apps in any language, that 
nobody uses.

>> Even Java got nowhere in the consumer GUI market, other than a 
>> few p2p apps like Vuze and the now-defunct Limewire, largely 
>> for piracy.
>
> JetBrain's products?

I wouldn't call developer tools consumer apps, as they're used by 
developers to do their job, so that doesn't really qualify.  I 
should also note that I meant consumer desktop GUI apps, as 
obviously Java does well on mobile, when it was made the default 
application language for Android, though they've paid the price 
for its inefficiency and lag and had to AoT-compile it starting 
with Lollipop.

>> While that market may be important to you, it is a small 
>> segment of the programming market.  It's nice that D libraries 
>> like Mir are targeting it, but it's not going to move the 
>> needle much.
>
> Mmm… it is a small segment of the revenue-based market, because 
> scientific programmers are often the scientists themselves (no 
> it is not important to me at the moment).  It is a fairly large 
> segment though of the overall market. As it includes a lot of 
> engineering. Just because those programs aren't sold, either 
> because they are in-house, personal or with a very narrow user 
> base (like researchers) doesn't mean that these programs are 
> less important.

I don't think it's a large percentage of programmers or programs 
either, leaving aside revenue.  It used to be a significant chunk 
decades ago, but I believe it has dwindled to a small percentage 
as computing has spread everywhere else.

>> You may not even know that's because of generic programming, 
>> you just like all the great libraries.  IOW, you may think you 
>> don't need generic programming, but the libraries you do need 
>> do need it.
>
> That's right, but you need critical mass for it to matter.

I've given you an estimate of D users, you haven't said why that 
hasn't passed your critical mass threshold.

> Otherwise people will just use somewhat slower or somewhat more 
> clunky libraries.  Go, Python and JavaScript are doing fine… 
> without proper generics.

As I noted in an earlier thread in this forum, I can build a bike 
in a couple hours and get going faster out of the gate up to a 
top speed of 30 km/h.  However, the guy building his own car will 
take longer but eventually zoom by me at 150 km/h.

Those languages got farther earlier, but that's no guarantee they 
win the race.

On Thursday, 4 January 2018 at 07:51:56 UTC, Paulo Pinto wrote:
> On Wednesday, 3 January 2018 at 16:20:48 UTC, Joakim wrote:
>> On Wednesday, 3 January 2018 at 11:43:35 UTC, Paulo Pinto 
>> wrote:
>>> On Wednesday, 3 January 2018 at 11:13:04 UTC, Joakim wrote:
>>>> On Wednesday, 3 January 2018 at 10:29:05 UTC, Ola Fosheim 
>>>> Grøstad wrote:
>>>>> On Wednesday, 3 January 2018 at 09:56:48 UTC, Pjotr Prins 
>>>>> wrote:
>>>>> [...]
>>>>
>>>>> Good programmers aren't stuck on any single language and 
>>>>> will pick the tool best suited for the job at hand.  Good 
>>>>> programmers are also good at picking up new languages.
>>>>
>>>> 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?
>>>> [...]
>>>
>>> Everyone at my employer, a few thousand of them doing 
>>> enterprise consulting.
>>>
>>> We specialize in a few large domains, and tend to jump 
>>> between them every 6 months or a year, when switching 
>>> projects.
>>>
>>> On my case, full stack development across JVM and .NET 
>>> languages, with C++ for low level coding.
>>
>> How many of those few thousand are actually comfortable with 
>> C++ for low-level coding?  I think you've said before that 
>> it's not many. So okay, your colleagues switch between Java 
>> and C#, which is somewhat uncommon as many places are pure C# 
>> or Java shops, but those are the two most popular enterprise 
>> application languages, noted for their similarities.
>>
>> You can hardly use this as an example of having a toolbox of 
>> languages and picking the best for the job, say Erlang for 
>> some high-concurrency microservice or ruby for an app you need 
>> to get up and running quickly.  You're just using two of the 
>> most popular business languages and deciding which based on 
>> what the customer wants.
>>
>
> Not all of them of them are comfortable with C++, that is true.
>
> But they are comfortable with other languages, which I am not.
>
> Notice that "JVM and .NET languages, with C++ for low level 
> coding." was my own skillset, not everyone at the company.
>
> Also I said JVM and .NET languages, not Java and C#. If you 
> want me to be more precise, Java, Clojure, C#, F#, VB.NET and 
> now getting into Kotlin due to future Android projects.
>
> I also do JavaScript, PL/SQL, pgSQL on occasion, and have 
> helped some iOS projects when an extra helping hand is needed 
> and I am low on project requests.
>
> I never like to specialize in any technology stack, it is the 
> best way to outdate myself on a market that is fashion driven.

I suspect you are one of the small handful I mentioned, even in 
your company, who's comfortable with so many languages.

> Of course there are lots of details I don't master in every 
> programming language, but as Wirth puts it, it is all about 
> mastering CS concepts, algorithms and data structures. Also why 
> Knuth used his own invented Assembly instead of choosing any 
> programming language.
>
> To actually know every detail of programming language, or what 
> its runtime library is capable of, there are books and web 
> sites to get it from.
>
> Soft skills and domain knowledge in each market are more 
> relevant than knowing every single detail of a programming 
> language.

I suspect that is what most at even your company do: focus on a 
single language, much more of its details, and all those non-CS 
skills you say are more important.  Which is fine, that has been 
the natural order of things, a few generalists like you 
interacting with a bunch of specialists.

On Thursday, 4 January 2018 at 13:07:37 UTC, Mengu wrote:
> On Wednesday, 3 January 2018 at 16:20:48 UTC, Joakim wrote:
>> On Wednesday, 3 January 2018 at 11:43:35 UTC, Paulo Pinto 
>> wrote:
>>> On Wednesday, 3 January 2018 at 11:13:04 UTC, Joakim wrote:
>>>> On Wednesday, 3 January 2018 at 10:29:05 UTC, Ola Fosheim 
>>>> Grøstad wrote:
>>>>> On Wednesday, 3 January 2018 at 09:56:48 UTC, Pjotr Prins 
>>>>> wrote:
>>>>> [...]
>>>
>>> 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.
>>
>> Python has done well in those niches, but when is the last 
>> time you saw a popular GUI app written in Python?  That is the 
>> largest segment of the market, and Python has basically no 
>> uptake there.  Even Java got nowhere in the consumer GUI 
>> market, other than a few p2p apps like Vuze and the 
>> now-defunct Limewire, largely for piracy.
>>
>
> you could not be more wrong. there are tons of python gui 
> applications. pygtk, pyqt and wxpython are great libraries that 
> allows you to create desktop apps very easy and fast. D does 
> not even have a good solution except for gtkD which is a one 
> man show. if it wasn't for Mike we would not even have it. 
> leadership does not care. remember qtd guys stopping everything 
> because a bug was not getting fixed?

Maybe I am, but you have not named a popular python GUI app like 
I asked, only some GUI frameworks that could be used to build 
such an app.  I wasn't saying that you couldn't write a python 
GUI app, but that it's probably not the best tool for the job.

> there's also one other thing: atom, vs code, spotify, slack are 
> all running on electron. does it make it a better platform than 
> python?

No, because it's still a bad framework, as posts like this show:

https://medium.com/@caspervonb/why-i-still-use-vim-67afd76b4db6

But at least they can show some real-world successes for app 
usage, even if they perform poorly because of the fundamental 
limitations of the language.  I don't think python has even 
gotten that far.