www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D has moved up to number 18!

reply Walter Bright <newshound digitalmars.com> writes:
http://www.tiobe.com/tpci.htm
Jun 05 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e62iae$13et$1 digitaldaemon.com...
 http://www.tiobe.com/tpci.htm

That's some serious wootage. Though what's with ColdFusion moving up to 20? Wasn't that some kind of side-of-the-road web language in the late 90s? Or has it had some kind of revival? And Visual FoxPro too.. weird.
Jun 05 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <e62qqh$1h7j$1 digitaldaemon.com>, Jarrett Billingsley says...
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e62iae$13et$1 digitaldaemon.com...
 http://www.tiobe.com/tpci.htm

That's some serious wootage.

W00t. We edged out Ruby. Very nice.
Though what's with ColdFusion moving up to 20?  Wasn't that some kind of 
side-of-the-road web language in the late 90s?  Or has it had some kind of 
revival? 

I can personally attest to ColdFusions merits and flaws as I use it on a daily basis - its not pretty, but it does put food on the table. AFAIK, its widely used on government contracts thanks to the forward-thinking individuals that put web applications in place there back in the early 90's - then it was the only game in town next to perl CGI and a very early rendition ASP. It was revitalized when Macromedia acquired Aleris and basically saved the language from itself by reworking it as a J2EE web language (same niche as JSP). The Java backend has done a lot for enabling interop with superior tools and libraries (all Java), as well as making server admins much happier. You can even compile CF apps down to .war files for deployment, or mix and match with jsp and vanilla Java code - so its like an alternate to the .NET stack for web applications. As far as revivals are concerned, you might be right. Macromedia had quite the corporate blogroll and press for this product, and it looks like Adobe is continuing the tradition and live documentation. CFMX7 just came out, so maybe its here to stay for a while longer. :-/ - EricAnderton at yahoo
Jun 05 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:e62rul$1j08$1 digitaldaemon.com...

 W00t.  We edged out Ruby.  Very nice.

Damn, I just noticed that! Take that, snooty esoteric interpreted languages!
 As far as revivals are concerned, you might be right. Macromedia had quite 
 the
 corporate blogroll and press for this product, and it looks like Adobe is
 continuing the tradition and live documentation.  CFMX7 just  came out, so 
 maybe
 its here to stay for a while longer. :-/

Bizarre. I haven't even heard ColdFusion mentioned for years.
Jun 05 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e62iae$13et$1 digitaldaemon.com...
 http://www.tiobe.com/tpci.htm

That's some serious wootage. Though what's with ColdFusion moving up to 20? Wasn't that some kind of side-of-the-road web language in the late 90s? Or has it had some kind of revival? And Visual FoxPro too.. weird.

I can't say why those have jumped up like they have, except to say that maybe it had something to do with TIOBE revising their query(ies) a while back. I think both Cold Fusion and Foxpro still get some pretty heavy use out there - I suspect there's *a lot* of legacy applications still in use, and a lot of independent developers (CF) and small software shops (Foxpro) using them. Foxpro inherited a lot of the Dbase development back in the day. One just never sees them mentioned in IT magazines or taught at Uni. any more.
Jun 05 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message

 I can't say why those have jumped up like they have, except to say that 
 maybe it had something to do with TIOBE revising their query(ies) a while 
 back.

That's possible - I wiki'ed FoxPro, and in fact, it was only in December of last year that FoxPro even made it into the top 20. So something weird had to have happened.
 I think both Cold Fusion and Foxpro still get some pretty heavy use out 
 there - I suspect there's *a lot* of legacy applications still in use, and 
 a lot of independent developers (CF) and small software shops (Foxpro) 
 using them.

Yeah, my father does still do some FoxPro from time to time when he's working on some small bussiness's databases (he's been a database engineer for umpteen years..).
Jun 05 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Dave wrote:
 Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e62iae$13et$1 digitaldaemon.com...
 http://www.tiobe.com/tpci.htm

That's some serious wootage. Though what's with ColdFusion moving up to 20? Wasn't that some kind of side-of-the-road web language in the late 90s? Or has it had some kind of revival? And Visual FoxPro too.. weird.

I can't say why those have jumped up like they have, except to say that maybe it had something to do with TIOBE revising their query(ies) a while back.

I think it's got more to do with this: http://fox.wikis.com/wc.dll?Wiki~GettingGoogledForTheTiobeMetricsCount I'm a little suspicious of the Tiobe metrics; there's clearly _some_ distortion happening.
 I think both Cold Fusion and Foxpro still get some pretty heavy use out 
 there - I suspect there's *a lot* of legacy applications still in use, 
 and a lot of independent developers (CF) and small software shops 
 (Foxpro) using them. Foxpro inherited a lot of the Dbase development 
 back in the day. One just never sees them mentioned in IT magazines or 
 taught at Uni. any more.

Jun 05 2006
parent reply Dave <Dave_member pathlink.com> writes:
Don Clugston wrote:
 Dave wrote:
 Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e62iae$13et$1 digitaldaemon.com...
 http://www.tiobe.com/tpci.htm

That's some serious wootage. Though what's with ColdFusion moving up to 20? Wasn't that some kind of side-of-the-road web language in the late 90s? Or has it had some kind of revival? And Visual FoxPro too.. weird.

I can't say why those have jumped up like they have, except to say that maybe it had something to do with TIOBE revising their query(ies) a while back.

I think it's got more to do with this: http://fox.wikis.com/wc.dll?Wiki~GettingGoogledForTheTiobeMetricsCount

Heh, heh - The few Foxpro developers I know are really pragmatic and getting together and "gaming TIOBE" for the good of Foxpro would be right up their alley <g> Hats off to them :) The last updated date on that corresponds to when the "jump" started to happen, I think... Still, it does speak to at least an active Foxpro community out there yet.
 
 I'm a little suspicious of the Tiobe metrics; there's clearly _some_ 
 distortion happening.
 
 I think both Cold Fusion and Foxpro still get some pretty heavy use 
 out there - I suspect there's *a lot* of legacy applications still in 
 use, and a lot of independent developers (CF) and small software shops 
 (Foxpro) using them. Foxpro inherited a lot of the Dbase development 
 back in the day. One just never sees them mentioned in IT magazines or 
 taught at Uni. any more.


Jun 06 2006
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave schrieb am 2006-06-06:
 Don Clugston wrote:

 I think it's got more to do with this:
 
 http://fox.wikis.com/wc.dll?Wiki~GettingGoogledForTheTiobeMetricsCount

Heh, heh - The few Foxpro developers I know are really pragmatic and getting together and "gaming TIOBE" for the good of Foxpro would be right up their alley <g> Hats off to them :)

Let's see what impact some white hats have: http://www.prowiki.org/wiki4d/wiki.cgi?PromotingD
 The last updated date on that corresponds to when the "jump" started to 
 happen, I think...

 Still, it does speak to at least an active Foxpro community out there yet.

from http://fox.wikis.com/wc.dll?Wiki%7ETiobeProgrammingLanguagePopularity # # VFP is actually above VB.NET and Cold Fusion now! # Looks like the older languages have some sort of advantage there since # Cobol is above vfp... # # and have simultaneously proved how irrelevant the site is. Still, it may # get more people interested in using it. # Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEhbmh3w+/yD4P9tIRAvenAJ9rgxore9LrllfL1nqPkLrvMJUJSACgxXth fMiRjyvMAcA32FeZxpnDytQ= =Csg5 -----END PGP SIGNATURE-----
Jun 06 2006
prev sibling parent reply Dejan Lekic <dejan nu6.org> writes:
I have expected that to happen. I would not be surprised if D comes to 
top5 languages on TIOBE's TPCI list by the end of this year, and become 
#1 by the end of next year.

As an experienced C/C++ developer (12+ years of commercial experience) i 
can only say that D will become language of choice whenever I am the one 
who decides what language to chose. I have very good reasons to do so.

1) Perfect scope() solution. Seriously, scope() keyword is IMHO one of 
the best new things i have seen so far - it shortens the code a lot, and 
puts necessary code where it belongs.

2) Amazing template support with solved syntax ambiguities.

3) Delegates.

4) Real modules. Packages and interfaces.

5) super keyword

6) array slicing

7) utf8 support

... and many more.

The only thing i really miss is better thread support. I have already 
proposed changes (about lock() keyword, and better thread 
synchronisation tuning), but you Mr. Bright did not respond. :) Some 
other guys did and they did like what i proposed.

*I have no words to express my apriciation for what you have done so 
far, and gave us all that for free.

Thank you Walter!*

Kind regards to you and whole D community.

Dejan Lekic
Jun 08 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Dejan Lekic wrote:
 The only thing i really miss is better thread support. I have already 
 proposed changes (about lock() keyword, and better thread 
 synchronisation tuning), but you Mr. Bright did not respond. :) Some 
 other guys did and they did like what i proposed.

Can you point me to the thread?
 *I have no words to express my apriciation for what you have done so 
 far, and gave us all that for free.
 
 Thank you Walter!*

You're welcome!
Jun 08 2006
parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e69jmh$bnq$1 digitaldaemon.com>, Walter Bright says...
Dejan Lekic wrote:
 The only thing i really miss is better thread support. I have already 
 proposed changes (about lock() keyword, and better thread 
 synchronisation tuning), but you Mr. Bright did not respond. :) Some 
 other guys did and they did like what i proposed.

Can you point me to the thread?

I guessing it's this: http://www.digitalmars.com/d/archives/digitalmars/D/35240.html jcc7
Jun 08 2006
parent reply Dejan Lekic <dejan nu6.org> writes:
Mr. (or Mrs.) jcc7, thank you - i have tried to find that post myself, but
failed! :)
Yes, that is a very nice thread, with many good ideas which followed.
In short, the basic idea is to move thread support INTO the language. 

Best regards!
Jun 08 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
Dejan Lekic wrote:
 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post myself, but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language. 
 
 Best regards!

I'd like to interject that, if more threading support is to be added to the language, it may be worthwhile to look into moving away from 'native threads' (including pthreads) into something more lightweight as the internal basis for D threading. Like the recently posted StackThreads library maybe(?). Many other languages (especially functional languages) are taking this approach - better performance, flexibility and portability. IMHO, it be best to either a) release v1.0 w/ thread support as-is and redesign it for v2 or b) delay v1 until it has any improvements Walter may deem worthy, because I can only see MT as becoming hugely important in the next couple of years.
Jun 08 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Dave wrote:
 Dejan Lekic wrote:
 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post myself, 
 but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language.
 Best regards!

I'd like to interject that, if more threading support is to be added to the language, it may be worthwhile to look into moving away from 'native threads' (including pthreads) into something more lightweight as the internal basis for D threading. Like the recently posted StackThreads library maybe(?). Many other languages (especially functional languages) are taking this approach - better performance, flexibility and portability.

Yes and no. With the number of processors on average systems increasing rapidly, there's definitely a place for kernel threads in today's world. IMO Solaris handles threading fairly well as it automatically uses both user threads and kernel threads for the pthread API based on some system knowledge and influenced by some API parameters. I like this better than cooperative user-level multithreading in most cases because it's easier to use and more flexible for the platform design, though it isn't quite so lightweight as mutexes and such must still be used.
 IMHO, it be best to either a) release v1.0 w/ thread support as-is and 
 redesign it for v2 or b) delay v1 until it has any improvements Walter 
 may deem worthy, because I can only see MT as becoming hugely important 
 in the next couple of years.

Definately. Sean
Jun 08 2006
parent reply Dave <Dave_member pathlink.com> writes:
Sean Kelly wrote:
 Dave wrote:
 Dejan Lekic wrote:
 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post 
 myself, but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language.
 Best regards!

I'd like to interject that, if more threading support is to be added to the language, it may be worthwhile to look into moving away from 'native threads' (including pthreads) into something more lightweight as the internal basis for D threading. Like the recently posted StackThreads library maybe(?). Many other languages (especially functional languages) are taking this approach - better performance, flexibility and portability.

Yes and no. With the number of processors on average systems increasing rapidly, there's definitely a place for kernel threads in today's world. IMO Solaris handles threading fairly well as it automatically uses both user threads and kernel threads for the pthread API based on some system knowledge and influenced by some API parameters. I like this better than cooperative user-level multithreading in most cases because it's easier to use and more flexible for the platform design, though it isn't quite so lightweight as mutexes and such must still be used.

I just had reason to take a look at the Solaris thread stuff the other day. Pretty cool. So, I guess the challenge may be to try and provide flexible enough language mods. and (a reference) rt lib/compiler interface to accommodate the best for a given platform?
 IMHO, it be best to either a) release v1.0 w/ thread support as-is and 
 redesign it for v2 or b) delay v1 until it has any improvements Walter 
 may deem worthy, because I can only see MT as becoming hugely 
 important in the next couple of years.

Definately. Sean

Jun 09 2006
parent reply Sean Kelly <sean f4.ca> writes:
Dave wrote:
 Sean Kelly wrote:
 Dave wrote:
 Dejan Lekic wrote:
 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post 
 myself, but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language.
 Best regards!

I'd like to interject that, if more threading support is to be added to the language, it may be worthwhile to look into moving away from 'native threads' (including pthreads) into something more lightweight as the internal basis for D threading. Like the recently posted StackThreads library maybe(?). Many other languages (especially functional languages) are taking this approach - better performance, flexibility and portability.

Yes and no. With the number of processors on average systems increasing rapidly, there's definitely a place for kernel threads in today's world. IMO Solaris handles threading fairly well as it automatically uses both user threads and kernel threads for the pthread API based on some system knowledge and influenced by some API parameters. I like this better than cooperative user-level multithreading in most cases because it's easier to use and more flexible for the platform design, though it isn't quite so lightweight as mutexes and such must still be used.

I just had reason to take a look at the Solaris thread stuff the other day. Pretty cool. So, I guess the challenge may be to try and provide flexible enough language mods. and (a reference) rt lib/compiler interface to accommodate the best for a given platform?

I think so. Personally, my main interest with new threading work is to provide something that avoids the need for direct of most synchronized blocks, thread construction, etc, as this stuff is notoriously difficult for even experienced programmers to get right. In the past I've mentioned Herb Sutter's Concur project in relation to this, and there has been some discussion of related projects and technology as well. Were D to set its sights on concurrent programming I'd much prefer it be at this level rather than focusing on the traditional approach. However, I think a good interim solution (and to simplify implementing library support for this sort of thing) would be to expand the traditional interface somewhat, at least to include condvars and perhaps try-locks. This can be done largely in library code (someone posted a condvar implementation a while back), but as it affects language semantics at least marginally I'd prefer it have some sort of official seal of approval. For Ares I've been fairly careful so far to limit most of my changes to what I felt was readily identifiable as library code, as I don't want to muddy the waters about what is legal D syntax. Sean
Jun 09 2006
parent reply Dave <Dave_member pathlink.com> writes:
In article <e6catg$10ck$1 digitaldaemon.com>, Sean Kelly says...
Dave wrote:
 Sean Kelly wrote:
 Dave wrote:
 Dejan Lekic wrote:
 Mr. (or Mrs.) jcc7, thank you - i have tried to find that post 
 myself, but
 failed! :)
 Yes, that is a very nice thread, with many good ideas which followed.
 In short, the basic idea is to move thread support INTO the language.
 Best regards!

I'd like to interject that, if more threading support is to be added to the language, it may be worthwhile to look into moving away from 'native threads' (including pthreads) into something more lightweight as the internal basis for D threading. Like the recently posted StackThreads library maybe(?). Many other languages (especially functional languages) are taking this approach - better performance, flexibility and portability.

Yes and no. With the number of processors on average systems increasing rapidly, there's definitely a place for kernel threads in today's world. IMO Solaris handles threading fairly well as it automatically uses both user threads and kernel threads for the pthread API based on some system knowledge and influenced by some API parameters. I like this better than cooperative user-level multithreading in most cases because it's easier to use and more flexible for the platform design, though it isn't quite so lightweight as mutexes and such must still be used.

I just had reason to take a look at the Solaris thread stuff the other day. Pretty cool. So, I guess the challenge may be to try and provide flexible enough language mods. and (a reference) rt lib/compiler interface to accommodate the best for a given platform?

I think so. Personally, my main interest with new threading work is to provide something that avoids the need for direct of most synchronized blocks, thread construction, etc, as this stuff is notoriously difficult for even experienced programmers to get right. In the past I've mentioned Herb Sutter's Concur project in relation to this, and there has been some discussion of related projects and technology as well. Were D to set its sights on concurrent programming I'd much prefer it be at this level rather than focusing on the traditional approach. However, I think a good interim solution (and to simplify implementing library support for this sort of thing) would be to expand the traditional interface somewhat, at least to include condvars and perhaps try-locks. This can be done largely in library code (someone posted a condvar implementation a while back), but as it affects language semantics at least marginally I'd prefer it have some sort of official seal of approval. For Ares I've been fairly careful so far to limit most of my changes to what I felt was readily identifiable as library code, as I don't want to muddy the waters about what is legal D syntax.

I think condvars and try-locks would be great (semaphores too)... I'm wondering if it would make sense for support of threads and related to just be added directly to the language? New keywords, a built-in thread type and all? Or something like building at least rudimentary OpenMP type functionality into the language? Ideally, I'd like to see thread/MP support such that it would eliminate much of the productivity advantages that languages that are supposed to be able to 'auto-parallelize' loops may have (like Sun's new 'Fortress'). For D these things would still be explicit, like it should be for a GP/systems orientated language, and would help keep the compiler implementation effort reasonable as well. I can see support like that lasting well into the next decade, until compilers or runtimes are truly smart-enough to do a really good job at auto-parallelization and such. That is, if the syntax and semantics can be made straight forward enough that better control is worth a bit more development time for the general case, then I think a statically compiled D could stay competitive in this area.
Jun 10 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Dave wrote:

 I think condvars and try-locks would be great (semaphores too)... I'm
 wondering if it would make sense for support of threads and related
 to just be added directly to the language? New keywords, a built-in
 thread type and all? Or something like building at least rudimentary
 OpenMP type functionality into the language?
 
 Ideally, I'd like to see thread/MP support such that it would
 eliminate much of the productivity advantages that languages that are
 supposed to be able to 'auto-parallelize' loops may have (like Sun's
 new 'Fortress').
 
 For D these things would still be explicit, like it should be for a
 GP/systems orientated language, and would help keep the compiler
 implementation effort reasonable as well. I can see support like that
 lasting well into the next decade, until compilers or runtimes are
 truly smart-enough to do a really good job at auto-parallelization
 and such. That is, if the syntax and semantics can be made straight
 forward enough that better control is worth a bit more development
 time for the general case, then I think a statically compiled D could
 stay competitive in this area.

[Sorry for vague terminology, etc., I've been up all night. :-/ ] I'd really like to have both cooperative threads _and_ thread and/or MP support. Of these two, I think cooperative threads is the bigger priority. It is also easier to implement (especially in a portable manner), and really it would behoove us to have a proper implementation in Phobos asap, and not only until D1.0! Especially when we have some very promising candidates already. --- As an aside, I can imagine quite a few applications where I'd use _both_ cooperative threads and preemptive threads. The parts that get used by cooperative threads only, would not need critical sections and thus be easy to write. Also, why not use them wherever they suffice. Only those places where both coop and preemptive manipulate something need critical sections and such. So, in such an application we could strive towards a clean separation of the tasks that can be done with each of the two (or more) main ("mutually pre-emptive") threads. Each could then "contain" possibly a number of cooperative threads -- without the whole thing becoming hard to manage. What comes to mind are serious games, especially multiplayer, process automation (yes I'm at it right now!), robotics (even toy robotics ;-) ), simulations, and real-time data streams control and manipulation. Or a heavy-duty word processor, programming environment, database GUI, or 3D model designer. (In those, the UI could be done with cooperative threads. Another thread (possibly even containing cooperative ("sub")threads) could then incrementally refine the rendition of objects, restructure data in the background, make "smarter" incremental temporary backups, etc.) --- Being tired right now, I can't figure out which (if any) changes to the D language, would be unavoidable to get both of these not only useful -- but smooth, elegant, obvious and natural to use?
Jun 13 2006
prev sibling parent reply Dejan Lekic <dejan nu6.org> writes:
Dave, i have thought of your StackThreads library too. IMHO there is no need
for such thing, for average D programmer. Sure, i could be wrong. :) - I
have no time to talk about reasons as i rush to go to work now. :)

Kind regards - btw. i like StackThreads!
Jun 08 2006
parent Dave <Dave_member pathlink.com> writes:
Dejan Lekic wrote:
 Dave, i have thought of your StackThreads library too. IMHO there is no need
 for such thing, for average D programmer. Sure, i could be wrong. :) - I
 have no time to talk about reasons as i rush to go to work now. :)
 
 Kind regards - btw. i like StackThreads!
 

I wish I could take credit for it, but I can't :) A Mr. Lysenko wrote it (credits are here): http://assertfalse.com/ <g> Frankly I haven't tried them out, but I think the idea has merit. I'll defer to the real experts on threading in this group as to the best way to approach things. The reason I brought it up is: if somewhat of a re-design is done, it *may* make sense to look into basing it on something other than kernel threads - but then again maybe not (as Sean describes in a previous post).
Jun 09 2006
prev sibling parent jcc7 <jcc7_member pathlink.com> writes:
In article <e6abkk$1i2d$1 digitaldaemon.com>, Dejan Lekic says...
Mr. (or Mrs.) jcc7, thank you - i have tried to find that post myself, but
failed! :)

I'm a guy. Some people call me Justin, but jcc7 is what I go by around here. ;) You're welcome. I found it quickly with the search box at http://www.digitalmars.com/d/index.html jcc7
Jun 09 2006