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