"pragma" <pragma_member@pathlink.com> wrote..

> Wow.  The feedback to those D posts is.. erm.. brutal.

Hmmm ... I thought it was quite moderate :)

Sure, there's one fool jiving on Z80, but I thought the other comments were pretty accurate :: it's a step in the right direction, but with no realistic library (yet), and no *obvious* sign of the backing needed to make an notable impact.

These are realistic criticisms.

On the other hand, the whole topic is immediately flawed :: it's almost all about Ruby. Ruby is great for writing throw-away code. Has anyone here actually tried to use it with say, 20 developers, over a multi-year project? It's not as though Ruby is actually new ~ been around for years. It's really, really hard to write large-scale, maintainable code in *any* scripting language (yes, I know there's one or two household names who use it ~ but do you also know their pain?)

The point is that Ruby et.al. are designed for scripting ~ a whole different ballgame than a systems language. One might well argue the pro's and con's of late- vs early- binding. Instead, I'll just note that Ruby, Perl, Python, VB, and a slew of others address a conceptually different set of problems than D. For example, D would be a good language to write a Ruby engine in. Would Python be an appropriate choice to write a Ruby interpreter? D would probably be a good choice to write "yet another back-office suite" (think PeopleSoft, Oracle, SAP :: payroll processing, etc), yet Perl would probably not be ...

As the industry matures, there's a high likelihood for the balance to shift between around between different types of languages (between, say, 3G and 4 or 5G). Yet you still have to pick the right tool for the job. Throwaway code is apparently becoming more and more popular (there's much less emphasis on long-term maintenance than there used to be), and processors are bob-awful fast these days compared to what they used to be. Not to mention the amounts of memory available. Still, another set of killer-apps will eventually come along that squeezes the hardware once again, and D will be right there for when that happens (just as C and C++ will be). I mean, we ain't gonna see a speech-recognition engine written in Ruby ~ at least, not this decade!

One final thought :: I really think D has the wrong target in mind. Walter seems to be interested in the desktop/server arena, yet the best place for D is actually the embedded market instead. We're talking about the most prevalent computers on the planet ~ they're in washing machines, vaccum cleaners, cars, ships, TV's, mp3 players, iPod's, cell-phones, blah blah blah. People don't use C++ there because it's way too bloated. They use C (and some assembler) because it's lightweight and fits the devices nicely. It's a huge market, just crying out for an 'upgrade' in terms of a language as a tool.

This is why I have an interest in getting D running on PocketPC. There's an enormous potential in the land of cell-phones and, frankly, I rather suspect that's the general direction of future platforms (as opposed to desktops). Why bother competing with C++ and/or Java when you can sidestep them (and all the associated cronyism) completely?

"pragma" <pragma_member@pathlink.com> wrote ...
> Good question.  For starters, such an app would have to be a non-toolchain
> kind
> of program; this would place it one tier above where most of us are
> concentrating right now.
>
> D's advantage over its competitors, in the hands of the end user, is in
> terms of
> program quality, size and speed.  I think this is a viable niche for a D
> "killer
> app" that could attract people to the technology.
>
> I read something on digg the other day about "microtorrent" which was
> warmly
> received even though it had pretty much the same feature set its
> competition.  I
> distinguished itself by being more responsive, smaller and faster than
> just
> about every other torrent tracker out there.  I'd like to think that
> particular
> software author managed to tap into something that users actually want.


Maybe, but I don't think most people care much about whether something is written in D or C. Both will give you similar results in the end, and what people notice is when things break. e.g. does it break my cell-phone (perhaps eat all the memory) when I do X? Programmers, and others who might appreciate the finer points of one solution over another, are in a rather small minority.

Thus, perhaps a general distinction for the developer becomes "which language has the most appropriate library" to get this job done? Other pain points may come into focus along the way, such as memory usage (in a limited environment) and performance (on a battery powered device).

In short, I don't think D has any particular redeeming feature that would lend itself toward a "D Killer App", rather than a "C++ Killer App". Instead, I think D needs a target market of developers who are actually *looking* for a better solution than what they currently have.

I think you should post that on slashdot as well!

Walter Bright wrote:
> I think you should post that on slashdot as well! 

Agreed.  However, threads on slashdot have an exceedingly short half-life--moderation stagnates a few hours after the topic appears at most.  So while it would be nice to have in there, few people may actually read it at this point.


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:drrrlt$2rb4$1@digitaldaemon.com...
> Walter Bright wrote:
>> I think you should post that on slashdot as well!
>
> Agreed.  However, threads on slashdot have an exceedingly short half-life--moderation stagnates a few hours after the topic appears at most.  So while it would be nice to have in there, few people may actually read it at this point.

The 'slashdot effect' for an article lasts about 24-48 hours (based on the surge of traffic at www.digitalmars.com when we're on slashdot). So you're right, the half-life is brief, but on the other hand, a lot of people are reached who would not otherwise have heard of D.

Walter Bright wrote:
> I think you should post that on slashdot as well! 

<g>

Actually, that was intended primarily for you to digest. Whilst it's just an opinion, I truly feel you should seriously consider the embedded market as the initial home for D. Here's some off-the-cuff reasoning:

a) Java & C++ have the desktop & server market sewn up for now (in non-scripting languages). Sure, you can try to challenge that from the basement level ~ but D needs some street cred to make it past the first stairwell. Java had a comparatively limitless budget, and there was a brand new hole needing to be plugged. What does D have to compete with? Good intentions alone are not enough to succeed.

b) The embedded market is stuck in C/assembler land. C++ is typically scorned in such environments, well deserved or not. Thus, it's a ripe market to address with D ~ a low overhead, efficient, robust language. One with a small learning curve, fast compiler, and a small library. The best of Java and C together. Sure, I may not use D for a micro-controller with 4KB; but that's fast becoming the exception for everyday devices. Combine D with cell-phones and a gazillion other new gadgets ... Seems like a no-brainer.

c) Believe it or not, you can still sell compilers to the embedded market. Four years ago, I paid over $2000 for a C compiler, questionable debugger, and emulator from Hitachi (t'was the only one available). You can probably still sell a good D compiler and debugger for $300 per seat. As you know, that kind of market disappeared long ago on the desktop ~ if it ain't free, forget it (how does the venerable Green-Hills stay in business these days? Is it the embedded market?)

Heck, GDC can apparently already compile targets for Arm/xscale devices. Yet there needs to be a full toolchain to make it worthy of more than a passing glance.

d) the embedded market is far more likely to give D "a go". Unlike the desktop/server world, there's generally far less investment into a particular or specific infrastructure. Often none. If an engineer can prove that D is faster to develop with and more robust, it's often a done deal. The environment is quite different than today's Java sweat-shops ~ in my humble experience it retains many of the good qualities from twenty years ago.

d) Building up some credibility in the embedded market also provides time to construct a decent (and robust) library set for other arenas. We all know there's an ocean missing there in terms of the desktop/server space (compared to C, C++, Java, Ruby, Python, VB etc). The embedded market prefers to get by without such fancy jewelry. They prefer just a solid toolchain with a language that exposes assembler, and can bind to C libs if necessary. Eliminating bugs early in the cycle is *the key* thing in that environment. It's just not economically feasible to patch devices once they're out on the street, so you *have* to get it correct up front. Can you say 'contracts' and 'bounds-checking', 'exception handling' and 'optional garbage collection'?



There's that question that keeps coming up year after year: "what does D target"? I think Matthew grumbled about it again just the other day, and it's one that I've certainly asked myself a number of times. The embedded market is the one place I can think of that would potentially embrace the language. In contrast, it's quite clear that the C++/Java arena would prefer to dispense scorn instead. That's not exactly unexpected at this point, but D would stand a much better chance of success if it had some true street-cred under its belt. And you might even make a bundle selling compilers in the meantime <g>

kris wrote:
> Walter Bright wrote:
>> I think you should post that on slashdot as well! 
> 
> <g>
> 
> Actually, that was intended primarily for you to digest. Whilst it's just an opinion, I truly feel you should seriously consider the embedded market as the initial home for D. Here's some off-the-cuff reasoning:
> 
> a) Java & C++ have the desktop & server market sewn up for now (in non-scripting languages). Sure, you can try to challenge that from the basement level ~ but D needs some street cred to make it past the first stairwell. Java had a comparatively limitless budget, and there was a brand new hole needing to be plugged. What does D have to compete with? Good intentions alone are not enough to succeed.
> 
> b) The embedded market is stuck in C/assembler land. C++ is typically scorned in such environments, well deserved or not. Thus, it's a ripe market to address with D ~ a low overhead, efficient, robust language. One with a small learning curve, fast compiler, and a small library. The best of Java and C together. Sure, I may not use D for a micro-controller with 4KB; but that's fast becoming the exception for everyday devices. Combine D with cell-phones and a gazillion other new gadgets ... Seems like a no-brainer.
> 
> c) Believe it or not, you can still sell compilers to the embedded market. Four years ago, I paid over $2000 for a C compiler, questionable debugger, and emulator from Hitachi (t'was the only one available). You can probably still sell a good D compiler and debugger for $300 per seat. As you know, that kind of market disappeared long ago on the desktop ~ if it ain't free, forget it (how does the venerable Green-Hills stay in business these days? Is it the embedded market?)
> 

LOL, I could walk to Green Hills from where I live! I might intern there this summer :-)
Yeah, they are all about embedded systems. (if that wasn't rhetorical)

> Heck, GDC can apparently already compile targets for Arm/xscale devices. Yet there needs to be a full toolchain to make it worthy of more than a passing glance.
> 
> d) the embedded market is far more likely to give D "a go". Unlike the desktop/server world, there's generally far less investment into a particular or specific infrastructure. Often none. If an engineer can prove that D is faster to develop with and more robust, it's often a done deal. The environment is quite different than today's Java sweat-shops ~ in my humble experience it retains many of the good qualities from twenty years ago.
> 
> d) Building up some credibility in the embedded market also provides time to construct a decent (and robust) library set for other arenas. We all know there's an ocean missing there in terms of the desktop/server space (compared to C, C++, Java, Ruby, Python, VB etc). The embedded market prefers to get by without such fancy jewelry. They prefer just a solid toolchain with a language that exposes assembler, and can bind to C libs if necessary. Eliminating bugs early in the cycle is *the key* thing in that environment. It's just not economically feasible to patch devices once they're out on the street, so you *have* to get it correct up front. Can you say 'contracts' and 'bounds-checking', 'exception handling' and 'optional garbage collection'?
> 
> 
> 
> There's that question that keeps coming up year after year: "what does D target"? I think Matthew grumbled about it again just the other day, and it's one that I've certainly asked myself a number of times. The embedded market is the one place I can think of that would potentially embrace the language. In contrast, it's quite clear that the C++/Java arena would prefer to dispense scorn instead. That's not exactly unexpected at this point, but D would stand a much better chance of success if it had some true street-cred under its belt. And you might even make a bundle selling compilers in the meantime <g>
> 

Solid reasoning. Does DMD have the ability to handle other assembler besides x86?

That all makes a *hell of a lot* of sense to me.

"kris" <fu@bar.org> wrote in message news:drsfap$7bk$1@digitaldaemon.com...
> Walter Bright wrote:
>> I think you should post that on slashdot as well!
>
> <g>
>
> Actually, that was intended primarily for you to digest. Whilst it's just an opinion, I truly feel you should seriously consider the embedded market as the initial home for D. Here's some off-the-cuff reasoning:
>
> a) Java & C++ have the desktop & server market sewn up for now (in non-scripting languages). Sure, you can try to challenge that from the basement level ~ but D needs some street cred to make it past the first stairwell. Java had a comparatively limitless budget, and there was a brand new hole needing to be plugged. What does D have to compete with? Good intentions alone are not enough to succeed.
>
> b) The embedded market is stuck in C/assembler land. C++ is typically scorned in such environments, well deserved or not. Thus, it's a ripe market to address with D ~ a low overhead, efficient, robust language. One with a small learning curve, fast compiler, and a small library. The best of Java and C together. Sure, I may not use D for a micro-controller with 4KB; but that's fast becoming the exception for everyday devices. Combine D with cell-phones and a gazillion other new gadgets ... Seems like a no-brainer.
>
> c) Believe it or not, you can still sell compilers to the embedded market. Four years ago, I paid over $2000 for a C compiler, questionable debugger, and emulator from Hitachi (t'was the only one available). You can probably still sell a good D compiler and debugger for $300 per seat. As you know, that kind of market disappeared long ago on the desktop ~ if it ain't free, forget it (how does the venerable Green-Hills stay in business these days? Is it the embedded market?)
>
> Heck, GDC can apparently already compile targets for Arm/xscale devices. Yet there needs to be a full toolchain to make it worthy of more than a passing glance.
>
> d) the embedded market is far more likely to give D "a go". Unlike the desktop/server world, there's generally far less investment into a particular or specific infrastructure. Often none. If an engineer can prove that D is faster to develop with and more robust, it's often a done deal. The environment is quite different than today's Java sweat-shops ~ in my humble experience it retains many of the good qualities from twenty years ago.
>
> d) Building up some credibility in the embedded market also provides time to construct a decent (and robust) library set for other arenas. We all know there's an ocean missing there in terms of the desktop/server space (compared to C, C++, Java, Ruby, Python, VB etc). The embedded market prefers to get by without such fancy jewelry. They prefer just a solid toolchain with a language that exposes assembler, and can bind to C libs if necessary. Eliminating bugs early in the cycle is *the key* thing in that environment. It's just not economically feasible to patch devices once they're out on the street, so you *have* to get it correct up front. Can you say 'contracts' and 'bounds-checking', 'exception handling' and 'optional garbage collection'?
>
>
>
> There's that question that keeps coming up year after year: "what does D target"? I think Matthew grumbled about it again just the other day, and it's one that I've certainly asked myself a number of times. The embedded market is the one place I can think of that would potentially embrace the language. In contrast, it's quite clear that the C++/Java arena would prefer to dispense scorn instead. That's not exactly unexpected at this point, but D would stand a much better chance of success if it had some true street-cred under its belt. And you might even make a bundle selling compilers in the meantime <g>
> 

Kyle Furlong wrote:
> Jari-Matti Mäkelä wrote:
>> pragma wrote:
>>> In article <drr6qr$25q6$1@digitaldaemon.com>, Kyle Furlong says...
>>>> pragma wrote:
>>>>> In article <pan.2006.02.01.20.06.12.251531@sneakemail.com>, =?iso-8859-1?q?Knud_S=F8rensen?= says...
>>>>>> Slashdot have just posted a story called beyond Java
>>>>>>
>>>>>> http://books.slashdot.org/article.pl?sid=06/02/01/1455213
>>>>> Wow.  The feedback to those D posts is.. erm.. brutal.
>>>>>
>>>>> Gotta love Slashdot.
>>>>>
>>>>> - Eric Anderton at yahoo
>>>> The question for us is, what "killer app" are we going to produce as a community.
>>> Good question.  For starters, such an app would have to be a
>>> non-toolchain kind
>>> of program; this would place it one tier above where most of us are
>>> concentrating right now.
>>>
>>> D's advantage over its competitors, in the hands of the end user, is
>>> in terms of
>>> program quality, size and speed.  I think this is a viable niche for
>>> a D "killer
>>> app" that could attract people to the technology.
>>
>> I think a real "killer app" would be a next generation desktop environment (e.g. D port of KDE using interpreted scripting languages and XML), but it would need to be written from scratch using D.
>>
>> The main advantages are that
>>  - D is more powerful than current functional languages
>>  - D is more reliable (=bug-free) than C/C++
>>  - D doesn't run under a virtual machine
>>  - it's easy to integrate garbage collecting scripting languages inside D
>>
>> Another great project would be a D operating system, but it's far too big a project for this community and eventually would not be able to produce enough hype around D.
>>
>>
> 
> What approximate LOC could be expected in a Firefox-like app?

A lot :) It depends on many things. Most users would probably want the html/xml-parser to be able to parse all kinds of invalid markup too. Then some others would like to have a file system browser integrated there. I guess a good point to start would be the (x)html rendering engine, khtml and gecko are both leaking a lot of memory. Maybe ~100 000 lines of code would be enough?

-- 
Jari-Matti

kris wrote:
> Walter Bright wrote:
>> I think you should post that on slashdot as well! 
> 
> <g>
> 
> Actually, that was intended primarily for you to digest. Whilst it's just an opinion, I truly feel you should seriously consider the embedded market as the initial home for D.

My response to your last post got lost somehow, so I'd just like to chime in again for the first time and say that I agree completely :-)


Sean