nemesis wrote:
> No, I'd say it's because C# the language is about as useful as Java the
> language:  not at all!  Both don't work outside their humongous associated
> libraries/frameworks.

Personally, I'm looking into Erlang right now, thinking about how it 
might work for the code I have at work. Looks pretty cool, but it's one 
of those things that it seems most of the stuff makes sense at the 
fundamental assignment/arithmetic/functioncall level, and then there are 
libraries for things like "Build a release of several applications that 
let you upgrade a running system along with the distributed database 
schema without shutting it down." So like the "kernel" and "stdlib" 
documents are together 800 pages (something like 60 pages of one-line 
descriptions for routines in Kernel), and all the stuff in between is 
just huge.

Contrast with C#, where each library is pretty well distinct, for the 
most part. You can read about the regexp library without even knowing 
about the existence of the dynamic-code-loading library.

I think for anything particularly useful, you're going to have big 
libraries anyway. It's hard to build an "enterprise" class application 
without a whole bunch of stuff, so why not design a library for 
enterprise-class applications and actually use it in your system? C#, I 
think, started out with the idea, rather than building it up without 
extensive language support like Java did.

Got the book on order, tho, so that should help.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Personally, I'm looking into Erlang right now... the "kernel" and "stdlib"
> documents are together 800 pages (something like 60 pages of one-line
> descriptions for routines in Kernel), and all the stuff in between is
> just huge.
>
> Contrast with C#, where each library is pretty well distinct, for the
> most part. You can read about the regexp library without even knowing
> about the existence of the dynamic-code-loading library.

Why is it any different with the Erlang library?  I've just taken a look at
stdlib in http://erlang.org/doc/pdf/ and, though a big document, the various
modules it describes as part of the "standard library" are clearly all distinct
and separate from each other, with an occasional reference to related
functionality in other modules.

Perhaps what bothered you is that the unmaintained docs are kept in PDF files
without links rather than a cross-referenced tree-based Windows Help file?

> I think for anything particularly useful, you're going to have big
> libraries anyway.

I didn't say otherwise.  I said .NET is closed and non-standardized and C#
without it is like bread and no butter -- well, much worse actually...

> It's hard to build an "enterprise" class application
> without a whole bunch of stuff, so why not design a library for
> enterprise-class applications and actually use it in your system?

Actually, the thing that p*** me off about Java libs or .NET or even Python etc
is that they're all just a bunch of redundant -- but perhaps a bit more
convenient -- wrappers to existing OS functionality.  In the case of Java or
Python at least, this leads to cross-platform ease.  In the case of .NET, it's
just Windows2 on top of Windows1, really, for no reason other than captivating
an evergoing mass of programming enterprise drones that prefer to type
FileAccess.ChangeDirectory(dir) rather than cd(dir) or something...

Post a reply to this message

nemesis wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Personally, I'm looking into Erlang right now... the "kernel" and "stdlib"
>> documents are together 800 pages (something like 60 pages of one-line
>> descriptions for routines in Kernel), and all the stuff in between is
>> just huge.
>>
>> Contrast with C#, where each library is pretty well distinct, for the
>> most part. You can read about the regexp library without even knowing
>> about the existence of the dynamic-code-loading library.
> 
> Why is it any different with the Erlang library? 

Look at anything other than the stdlib module.  I'm still wading thru 
kernel, but stuff like understanding the supervisor model, or the 
release application, or the mnesia stuff, requires a whole bunch of 
background.  (Not that it's hard to find the background. It's just 
there's a whole lot of it.)

C# probably has a lot of similar stuff, like when you're doing code 
generation and such. Understanding "assemblies" for example takes a lot 
of background, but doing something with assemblies that needs that 
understanding that stuff is unusual rather than step one.

In other words, I can't imagine why you'd want to use Erlang for a 
system other than a system that takes advantage of all the difficult 
stuff, while I can easily imagine using C# to do nothing more than a bit 
of simple XML parsing or some file management sort of thing.

It's entirely possible I'm reading Erlang docs in the wrong order. :-) 
I'm still trying to figure out where the parser is described. Various 
routines seem to imply you can add your own parsing to the language 
("behaviors" and "records" come to mind), as well as manipulating 
parse-trees, and I'm curious to see what that's all about.

> Perhaps what bothered you is that the unmaintained docs are kept in PDF files
> without links rather than a cross-referenced tree-based Windows Help file?

No, they have fine cross-references. It's just hard to know where to 
start. In retrospect, starting with kernel and stdlib is probably best, 
but I figured that out by reading the part in the release management app 
that said you had to include those in every release. :-)

>> I think for anything particularly useful, you're going to have big
>> libraries anyway.
> 
> I didn't say otherwise.  I said .NET is closed and non-standardized and C#
> without it is like bread and no butter -- well, much worse actually...

Yeah. And Erlang without the standard libraries (including gen_server, 
sasl, etc) isn't especially useful either.

> Actually, the thing that p*** me off about Java libs or .NET or even Python etc
> is that they're all just a bunch of redundant -- but perhaps a bit more
> convenient -- wrappers to existing OS functionality.

I would disagree. Certainly a large part of what you might use in some 
types of programs is like that. But if you're writing an ASP.NET 
program, most of the stuff you're doing has zero to do with the OS. 
Indeed, for that stuff, I understand that the executables are directly 
portable between MS's .NET and Mono.

> In the case of Java or Python at least, this leads to cross-platform ease.  

Yeah, right. Let me know when you have cross-JVM ease, let alone 
cross-platform ease, with Java.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:
> nemesis wrote:
>> Darren New <dne### [at] sanrrcom> wrote:
>>> I think for anything particularly useful, you're going to have big
>>> libraries anyway.
>>
>> I didn't say otherwise.  I said .NET is closed and non-standardized 
>> and C#
>> without it is like bread and no butter -- well, much worse actually...
> 
> Yeah. And Erlang without the standard libraries (including gen_server, 
> sasl, etc) isn't especially useful either.

Yes, except Erlang's libraries aren't closed technologies dictated by a 
single monopolistic company trying to pass it as free and open by 
standardizing just the language and very basic library.  Anyone can 
benefit, anyone can contribute and anyone can use without fear of 
dependencies of closed technologies that change depending on 
market/financial mood.

>> In the case of Java or Python at least, this leads to cross-platform 
>> ease.  
> 
> Yeah, right. Let me know when you have cross-JVM ease, let alone 
> cross-platform ease, with Java.

I run most Java or Python programs unmodified both at the WinBox at work 
and at my Linux home box.  The guy coding them doesn't have to worry 
about hairy ifdefs or memory management to get it working on different 
platforms.  The only requirement is that he uses the standard 
cross-platform API and doesn't rely on specific platform services.

Post a reply to this message

> I run most Java or Python programs unmodified both at the WinBox at work 
> and at my Linux home box.  The guy coding them doesn't have to worry 
> about hairy ifdefs or memory management to get it working on different 
> platforms.  The only requirement is that he uses the standard 
> cross-platform API and doesn't rely on specific platform services.

I saw a post in worsethanfailure of a Java method to copy files. It 
created a .bat file with a 'copy' command, then ran it, and finally 
deleted the .bat.

Post a reply to this message

nemesis wrote:
> I run most Java or Python programs unmodified both at the WinBox at work 
> and at my Linux home box. 

You're probably not doing too much hairy. I have to have three different 
JVMs installed at work to use three different libraries from three 
different partners.

I was always amused by the taglines that said things like
    100% Java! (Requires Java 1.5.2)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Nicolas Alvarez wrote:

>> I run most Java or Python programs unmodified both at the WinBox at 
>> work and at my Linux home box.  The guy coding them doesn't have to 
>> worry about hairy ifdefs or memory management to get it working on 
>> different platforms.  The only requirement is that he uses the 
>> standard cross-platform API and doesn't rely on specific platform 
>> services.
> 
> I saw a post in worsethanfailure of a Java method to copy files. It 
> created a .bat file with a 'copy' command, then ran it, and finally 
> deleted the .bat.

yes, even Java with all its stupid "enterprise" limitations is 
completely fool-proof!

Post a reply to this message

On Fri, 14 Mar 2008 18:38:46 +0000, Orchid XP v7 wrote:

>>> Now you know why I dislike scripting languages in general. ;-)
>> 
>> They work for what they're designed for - I use awk quite a bit, perl
>> occasionally, and shell scripts on rare occasions.
>> 
>> But if I wanted to write something that was usuable by a general
>> computer user, I'd look to develop in a compiled language, as a general
>> rule.
> 
> The kind of tasks I typically want to do involve heavy number crunching.
> Scripting languages aren't terribly suitable to this...

Scripting languages aren't designed for performance, as a general rule, 
so yes, that wouldn't be appropriate for a scripting language if you have 
complex calculations or lots of data to process.

Jim

Post a reply to this message

Jim Henderson wrote:

>> The kind of tasks I typically want to do involve heavy number crunching.
>> Scripting languages aren't terribly suitable to this...
> 
> Scripting languages aren't designed for performance, as a general rule, 
> so yes, that wouldn't be appropriate for a scripting language if you have 
> complex calculations or lots of data to process.

This is the problem with POV-Ray's SDL. People *have* built physics 
engines with it, but it's really not fantastically suitable for that task...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Wed, 26 Mar 2008 11:12:04 +0000, Orchid XP v7 wrote:

> Jim Henderson wrote:
> 
>>> The kind of tasks I typically want to do involve heavy number
>>> crunching. Scripting languages aren't terribly suitable to this...
>> 
>> Scripting languages aren't designed for performance, as a general rule,
>> so yes, that wouldn't be appropriate for a scripting language if you
>> have complex calculations or lots of data to process.
> 
> This is the problem with POV-Ray's SDL. People *have* built physics
> engines with it, but it's really not fantastically suitable for that
> task...

Well, I don't know that I'd call it a problem per se, more of a 
limitation to be aware of.

Jim

Post a reply to this message