www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Well, well...

reply "James K Smith" <jksmith dx-machine.com> writes:
I've been blathering for about two years over in Delphi land that the next
big thing in computing was the internet as a platform in and of itself - the
OS is reduced to another backend, like a db server, whatever. The remote end
user will give a crap less what OS is hosting the app, as long as that app
meets expectations. To make the internet fully realized, two issues have to
be addressed:

1) Proof of correctness in code. The days of no real or implied liability
are coming to an end, because even trivial  applications become
mission-critical when they are service providers. Extensive use of unit
testing and contract programming show best effort on behalf of the
manufacturer, which an educated business community will eventually pay more
for.

2) True concurrency instead of just simplistic threads and cores. If a unit
of computing power is available somewhere, I want the option to be able to
use it for my app.

I've groaned for these features for quite a while for other languages, and
even dabbled in Eiffel for a bit, but I've never come across a language that
has developed so much critical mass for this specific functionality. And
like icing on the cake, I get array slices back, which I haven't enjoyed
using since my Stony Brook Modula-2 dos days. It's like somebody asked me
what I wanted to see in a language and libs without really asking me.

Kudos to Mr. Bright and all the developers working to grow the community.
And thanks to Code::Blocks actually working with D and ddbg out of the box,
I'm already coding.

James
Aug 01 2007
parent reply "Nick Sabalausky" <a a.a> writes:
"James K Smith" <jksmith dx-machine.com> wrote in message 
news:f8rk7u$271m$1 digitalmars.com...
 I've been blathering for about two years over in Delphi land that the next
 big thing in computing was the internet as a platform in and of itself - 
 the
 OS is reduced to another backend, like a db server, whatever. The remote 
 end
 user will give a crap less what OS is hosting the app, as long as that app
 meets expectations. To make the internet fully realized, two issues have 
 to
 be addressed:

 1) Proof of correctness in code. The days of no real or implied liability
 are coming to an end, because even trivial  applications become
 mission-critical when they are service providers. Extensive use of unit
 testing and contract programming show best effort on behalf of the
 manufacturer, which an educated business community will eventually pay 
 more
 for.

 2) True concurrency instead of just simplistic threads and cores. If a 
 unit
 of computing power is available somewhere, I want the option to be able to
 use it for my app.

 I've groaned for these features for quite a while for other languages, and
 even dabbled in Eiffel for a bit, but I've never come across a language 
 that
 has developed so much critical mass for this specific functionality. And
 like icing on the cake, I get array slices back, which I haven't enjoyed
 using since my Stony Brook Modula-2 dos days. It's like somebody asked me
 what I wanted to see in a language and libs without really asking me.

 Kudos to Mr. Bright and all the developers working to grow the community.
 And thanks to Code::Blocks actually working with D and ddbg out of the 
 box,
 I'm already coding.

 James
I've always felt that the main thing holding the Internet back from being an OS-commoditizing platform are all of the design and implementation flaws in all the technologies the web is built on. HTML, JavaScript, ASP, PHP, browsers, etc. I could go forever listing problems I have with them, but I'll list just a few at random and leave it at that: 1. In HTML, "method" and "action" should be attributes of a submit button tag, not attributes of the form tag. 2. Web programming languages need to evolve from the scripting languages they are today into real professional languages (like D :) ). Dynamic-typing/duck-typing in particular need to go (pet peeve). Most of the web scripting languages out there are fine if you’re whipping up “Lil’ Coder’s First PHP Page”, but when you have a full-blown web app to maintain, those languages just send productivity and reliability straight down the crapper. 3. BROWSERS!!! Arrgghh! (Sorry for all the rantyness. I've been trapped in the web application world for a number of years now and I think it's draining my last bit of sanity.) But I do agree that we could use more developments in the area of concurrency. And I *strongly* agree on placing a high focus on techniques to maximize code reliability. That's something I've focused a lot on lately (Reliability and productivity without sacrificing power is what drew me to D in the first place).
Aug 01 2007
next sibling parent reply "James Smith" <jksmith grid-sky.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:f8rt59$2jki$1 digitalmars.com...
 I've always felt that the main thing holding the Internet back from being 
 an OS-commoditizing platform are all of the design and implementation 
 flaws in all the technologies the web is built on. HTML, JavaScript, ASP, 
 PHP, browsers, etc. I could go forever listing problems I have with them, 
 but I'll list just a few at random and leave it at that:
Sure, but this is just a growing pain. Personal computing has to evolve from each user on his own little island to being plugged into a grid. Naturally, forces like MSFT will discourage this as long as they can, then relent by degrees and figure out how to make money in the new environment. For all the quirks, the browser delivers an increasingly sophisticated OS agnostic user interface.
 But I do agree that we could use more developments in the area of 
 concurrency.
I think this is the next big frontier of computing. Combined with wireless technologies, it will ultimately result in our looking at computers in a completely different way. We'll relegate of the old way of interacting with "personal computers" to the same level of the old "sneakernet" back in dos days, when we would do some work, then run down the hall with a 5.25 floppy in our hands to share the work with someone else. I'm sure some smarties at IBM had this all figured out when they developed the "personal computer" and snickered at the new name, but history had to happen to get us to this point. Real concurrency will mean just as much a seachange as the original introduction of the pc in the early '80s.
And I *strongly* agree on placing a high focus on techniques to maximize 
code reliability. That's something I've focused a lot on lately 
(Reliability and productivity without sacrificing power is what drew me to 
D in the first place).
Absolutely, real concurrency won't be achievable without coinciding focus on reliable computing, which is why I'm so enthused about how D development is going. Apparently, real effort is being put into these issues in this James
Aug 02 2007
parent reply "Nick Sabalausky" <a a.a> writes:
"James Smith" <jksmith grid-sky.com> wrote in message 
news:f8sqne$1bp1$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message 
 news:f8rt59$2jki$1 digitalmars.com...
 I've always felt that the main thing holding the Internet back from being 
 an OS-commoditizing platform are all of the design and implementation 
 flaws in all the technologies the web is built on. HTML, JavaScript, ASP, 
 PHP, browsers, etc. I could go forever listing problems I have with them, 
 but I'll list just a few at random and leave it at that:
Sure, but this is just a growing pain. Personal computing has to evolve from each user on his own little island to being plugged into a grid. Naturally, forces like MSFT will discourage this as long as they can, then relent by degrees and figure out how to make money in the new environment. For all the quirks, the browser delivers an increasingly sophisticated OS agnostic user interface.
[clipped...]
And I *strongly* agree on placing a high focus on techniques to maximize 
code reliability. That's something I've focused a lot on lately 
(Reliability and productivity without sacrificing power is what drew me to 
D in the first place).
Absolutely, real concurrency won't be achievable without coinciding focus on reliable computing, which is why I'm so enthused about how D development is going. Apparently, real effort is being put into these issues in this community. These issues appear to hold little value in
Right. And from what I've seen, those issues haven't been holding much value in other web scripting languages (server- or client-side), either. Which, as it sounds like we're both saying, is something that will have to change before the web can reach it's potential. The worlds of Java and C++ do seem to care about reliable computing, but IMO they tend to be prone to missteps and are still lagging behind D in both reliability and pragmatism/produtivity. (Although Java has been making at least some good strides in pragmatism: 1.5 is a welcome improvement over 1.4, it finally adds things like foreach). I'm not trying to de-emphasise concurrency, it's just that reliability and productivity are where my focuses have been lately, so that's what I have the most to say about. My only experience with concurrency has been just with one microcontroller (Parallax's Propeller).
Aug 02 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 I'm not trying to de-emphasise concurrency, it's just that reliability and 
 productivity are where my focuses have been lately, so that's what I have 
 the most to say about. My only experience with concurrency has been just 
 with one microcontroller (Parallax's Propeller).
I'm beginning to suspect that many issues that surround concurrency are related to reliability - issues like better modularity.
Aug 02 2007
parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Nick Sabalausky wrote:
 I'm not trying to de-emphasise concurrency, it's just that reliability 
 and productivity are where my focuses have been lately, so that's what 
 I have the most to say about. My only experience with concurrency has 
 been just with one microcontroller (Parallax's Propeller).
I'm beginning to suspect that many issues that surround concurrency are related to reliability - issues like better modularity.
I think this is true. Concurrency designed around message passing is far more scalable than concurrency involving shared state, for example, and message passing is really nothing more than a mechanism to increase modularity. In fact, I've pretty much decided recently that concurrent programming is really slowly working towards a pure message-passing design similar to Erlang, and that library solutions in traditional imperative languages are simply attempts to extend the useful life of existing code (futures, etc). What I would personally find most interesting is if systems programming facilities were exposed in such a language, since this would provide a solid mapping between a task and a CPU. From what I gather, Erlang currently calls C routines for much of the performance-critical or low-level work, and the need to integrate two languages doesn't seem terribly ideal, assuming everything could be elegantly combined. As an aside, one interesting aspect of Erlang is that it turns code reliability on its head to a degree by simply aborting the process if an exception occurs. This seems far preferable to the manual exception recovery typically done in C++, Java, and D, which reduces code clarity and can be difficult to get right. Concepts like DBC, however, provide a quite useful degree of boundary checking, and seem applicable regardless of the degree of modularity introduced. Sean
Aug 02 2007
next sibling parent reply Robert Fraser <fraserogfthenight gmail.com> writes:
 I think this is true.  Concurrency designed around message passing is 
 far more scalable than concurrency involving shared state, for example, 
 and message passing is really nothing more than a mechanism to increase 
 modularity.  In fact, I've pretty much decided recently that concurrent 
 programming is really slowly working towards a pure message-passing 
 design similar to Erlang, and that library solutions in traditional 
 imperative languages are simply attempts to extend the useful life of 
 existing code (futures, etc).
SO how about a thread-pool based message-passing actor model in Tango :-)?
 As an aside, one interesting aspect of Erlang is that it turns code 
 reliability on its head to a degree by simply aborting the process if an 
 exception occurs.  This seems far preferable to the manual exception 
 recovery typically done in C++, Java, and D, which reduces code clarity 
 and can be difficult to get right.  Concepts like DBC, however, provide 
 a quite useful degree of boundary checking, and seem applicable 
 regardless of the degree of modularity introduced.
Depends what type of exception. The concept of "exception" is being used to represent both bugs/unexpected state in the code (which should be handled explicitly by the coder) and unexpected circumstances in resources. Should your web browser halt if it can't connect to a server? Should your word processor halt if it tries to save to a read-only file? These are the situations where exceptions are far clearer than C's way of dealing with error codes, etc.
Aug 02 2007
parent reply Sean Kelly <sean f4.ca> writes:
Robert Fraser wrote:
 I think this is true.  Concurrency designed around message passing is 
 far more scalable than concurrency involving shared state, for example, 
 and message passing is really nothing more than a mechanism to increase 
 modularity.  In fact, I've pretty much decided recently that concurrent 
 programming is really slowly working towards a pure message-passing 
 design similar to Erlang, and that library solutions in traditional 
 imperative languages are simply attempts to extend the useful life of 
 existing code (futures, etc).
SO how about a thread-pool based message-passing actor model in Tango :-)?
Concurrency support in Tango will definitely be expanded as time goes on :-)
 As an aside, one interesting aspect of Erlang is that it turns code 
 reliability on its head to a degree by simply aborting the process if an 
 exception occurs.  This seems far preferable to the manual exception 
 recovery typically done in C++, Java, and D, which reduces code clarity 
 and can be difficult to get right.  Concepts like DBC, however, provide 
 a quite useful degree of boundary checking, and seem applicable 
 regardless of the degree of modularity introduced.
Depends what type of exception. The concept of "exception" is being used to represent both bugs/unexpected state in the code (which should be handled explicitly by the coder) and unexpected circumstances in resources. Should your web browser halt if it can't connect to a server? Should your word processor halt if it tries to save to a read-only file? These are the situations where exceptions are far clearer than C's way of dealing with error codes, etc.
It shouldn't halt, but a sub-process handling some portion of the web-page loading might. Say you launch a process to grab the HTML and it in turn launches additional processes to get the images, etc, which need to be displayed. Any one of these processes may encounter an error and abort, but the browser would continue to run and the rest of the page would still load. The key, I think, is considering processes in Erlang to be a bit like classes or modules in D. Exception recovery isn't done simply because the cost of starting a process is so low that there's no reason to bother--just spawn a new process and try again. Sean
Aug 02 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Sean,

 It shouldn't halt, but a sub-process handling some portion of the
 web-page loading might.  Say you launch a process to grab the HTML and
 it in turn launches additional processes to get the images, etc, which
 need to be displayed.  Any one of these processes may encounter an
 error and abort, but the browser would continue to run and the rest of
 the page would still load.
in short, a process is small enought that all errors are fatal (to it) ?
  The key, I think, is considering processes
 in Erlang to be a bit like classes or modules in D.
or stack frames?
  Exception
 recovery isn't done simply because the cost of starting a process is
 so low that there's no reason to bother--just spawn a new process and
 try again.
 
 Sean
 
Aug 02 2007
parent Sean Kelly <sean f4.ca> writes:
BCS wrote:
 Reply to Sean,
 
 It shouldn't halt, but a sub-process handling some portion of the
 web-page loading might.  Say you launch a process to grab the HTML and
 it in turn launches additional processes to get the images, etc, which
 need to be displayed.  Any one of these processes may encounter an
 error and abort, but the browser would continue to run and the rest of
 the page would still load.
in short, a process is small enought that all errors are fatal (to it) ?
Yup. And it may be that Erlang does actually allow recovery from errors (I only know what I've read so far, and that's relatively little), but I think I'd probably only use this for failing more gracefully.
  The key, I think, is considering processes
 in Erlang to be a bit like classes or modules in D.
or stack frames?
Yeah I suppose. Though I was going more for processes as lightweight services. Similar things are done in languages like Java and C++ now (RMI, etc), but the services there tend to be heavy-weight. In Erlang it seems common to even perform recursion and such via process spawning. Sean
Aug 02 2007
prev sibling parent reply Mike Capp <mike.capp gmail.com> writes:
Sean Kelly Wrote:

 As an aside, one interesting aspect of Erlang is that it turns code 
 reliability on its head to a degree by simply aborting the process if an 
 exception occurs.  This seems far preferable to the manual exception 
 recovery typically done in C++, Java, and D, which reduces code clarity 
 and can be difficult to get right. 
Cough, splutter. That's fine, as long as you place zero value on whatever unsaved work the user had done, and you're confident that your users will share your Zen-like equanimity. What's true in telecoms isn't necessarily true everywhere. From other angles, though, the "just crash" approach has some intriguing possibilities. If it's your default means of exiting, chances are your app will be pretty robust when faced with unexpected failures. There was some interesting academic work about a year ago on "crash-only programming"; see e.g. http://lwn.net/Articles/191059/ cheers Mike
Aug 02 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Mike Capp wrote:
 Sean Kelly Wrote:
 
 As an aside, one interesting aspect of Erlang is that it turns code 
 reliability on its head to a degree by simply aborting the process if an 
 exception occurs.  This seems far preferable to the manual exception 
 recovery typically done in C++, Java, and D, which reduces code clarity 
 and can be difficult to get right. 
Cough, splutter. That's fine, as long as you place zero value on whatever unsaved work the user had done, and you're confident that your users will share your Zen-like equanimity. What's true in telecoms isn't necessarily true everywhere.
True. But I think graceful recovery could be done as well. That silly video Dave Abrahams linked showed errors being trapped and processes restarted, so I imagine a similar mechanism could rollback DB operations, etc, as necessary.
 From other angles, though, the "just crash" approach has some intriguing
possibilities. If it's your default means of exiting, chances are your app will
be pretty robust when faced with unexpected failures. There was some
interesting academic work about a year ago on "crash-only programming"; see
e.g. http://lwn.net/Articles/191059/
It's pretty popular in high availability systems, though this is the first I've thought of using it for portions of a user-level program. Sean
Aug 02 2007
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Mike Capp" <mike.capp gmail.com> wrote in message 
news:f8to1p$215$1 digitalmars.com...
 Cough, splutter.

 That's fine, as long as you place zero value on whatever unsaved work the 
 user had done, and you're confident that your users will share your 
 Zen-like equanimity. What's true in telecoms isn't necessarily true 
 everywhere.
I've used an app written in Erlang -- Wings3D -- fairly extensively, and I can tell you that the program _never crashes_. If there is an error somewhere, sometimes I'll get a gray screen telling me "hey this crashed, I made a crash log" but then the program picks right back up where it left off. Not really any different than an exception report.
Aug 03 2007
parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Jarrett Billingsley wrote:
 I've used an app written in Erlang -- Wings3D -- fairly extensively, and I 
 can tell you that the program _never crashes_.  If there is an error 
 somewhere, sometimes I'll get a gray screen telling me "hey this crashed, I 
 made a crash log" but then the program picks right back up where it left 
 off.  Not really any different than an exception report. 
Yes, that's because Erlang supports a mechanism know as process monitoring in which for most process another process is launched whose sole task is checking up the behavior of the first one. Process are so cheap that you can "waste" one process to monitor another and relaunch it if it crashes.
Aug 03 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Julio César Carrascal Urquijo Wrote:

 Jarrett Billingsley wrote:
 I've used an app written in Erlang -- Wings3D -- fairly extensively, and I 
 can tell you that the program _never crashes_.  If there is an error 
 somewhere, sometimes I'll get a gray screen telling me "hey this crashed, I 
 made a crash log" but then the program picks right back up where it left 
 off.  Not really any different than an exception report. 
Yes, that's because Erlang supports a mechanism know as process monitoring in which for most process another process is launched whose sole task is checking up the behavior of the first one. Process are so cheap that you can "waste" one process to monitor another and relaunch it if it crashes.
Wow, that sounds a lot more complicated than exceptions to do effectively the same thing.
Aug 03 2007
parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Robert Fraser wrote:
 Julio César Carrascal Urquijo Wrote:
 Yes, that's because Erlang supports a mechanism know as process 
 monitoring in which for most process another process is launched whose 
 sole task is checking up the behavior of the first one. Process are so 
 cheap that you can "waste" one process to monitor another and relaunch 
 it if it crashes.
Wow, that sounds a lot more complicated than exceptions to do effectively the same thing.
Not quite. This is more of a guardian process as implemented as by Apache or FirebirdSQL in which the guardian restarts a process if it has miss-behaved but in the case of Erlang is almost one guardian process for each process working.
Aug 04 2007
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 (Reliability and productivity without sacrificing power is what drew me to D 
 in the first place). 
While there's a lot of disagreement over how to achieve the goals, a big design objective for D is to support reliability, accountability, and auditability.
Aug 02 2007