On 20/05/2009 02:12, Walter Bright wrote:
Not even this book cover could save Forth!
http://www.globalnerdy.com/2007/09/14/reimagining-programming-book-covers/
Ah, Julie Bell and Boris Vallejo, one (well, two) of my favorite fantasy
artists, they're pretty awesome.
--
Bruno Medeiros -
I do not wish to recompile a 1.5GB standalone executable if I just
changed a minor version of a lib.
Can you tell me, why that application needs to be that big, and can't be
split in several, smaller processes?
Hello Yigal,
BCS wrote:
Reply to Yigal,
BCS wrote:
Hello Yigal,
C# assemblies are analogous to C/C++/D libs.
you can't create a standalone executable in D just by parsing the
D
source files (for all the imports) if you need to link in external
libs.
you need to at least specify the lib
Hello grauzone,
I do not wish to recompile a 1.5GB standalone executable if I just
changed a minor version of a lib.
Can you tell me, why that application needs to be that big, and can't
be split in several, smaller processes?
I'm more interested in how you got 1.5GBs of executable.
BCS Wrote:
What I want is a language where most of the time you build
a project from only the information in the source code.
There is nothing in C# that stops you doing exactly this.
You can build this Simple.cs file:
using System;
using System.Windows.Forms;
namespace
BCS wrote:
Hello Yigal,
C# assemblies are analogous to C/C++/D libs.
you can't create a standalone executable in D just by parsing the D
source files (for all the imports) if you need to link in external libs.
you need to at least specify the lib name if it's on the linker's
search path or
Reply to Yigal,
BCS wrote:
Hello Yigal,
C# assemblies are analogous to C/C++/D libs.
you can't create a standalone executable in D just by parsing the D
source files (for all the imports) if you need to link in external
libs.
you need to at least specify the lib name if it's on the linker's
Hello Christopher,
BCS wrote:
But that's not the point. Neither make nor VS's equivalent is what
this thread was about. At least not where I was involved. My point is
that the design of c# *requiters* the maintenance (almost certainly
by a c# specific IDE) of some kind of external metadata
Yigal Chripun wrote:
...
this I completely disagree with. those are the same faulty reasons I
already answered.
an IDE does _not_ create bad programmers, and does _not_ encourage bad
code. it does encourage descriptive names which is a _good_ thing.
writing strcpy ala C style is cryptic
BCS wrote:
Hello Christopher,
BCS wrote:
But that's not the point. Neither make nor VS's equivalent is what
this thread was about. At least not where I was involved. My point is
that the design of c# *requiters* the maintenance (almost certainly
by a c# specific IDE) of some kind of external
Hello Yigal,
C# assemblies are analogous to C/C++/D libs.
you can't create a standalone executable in D just by parsing the D
source files (for all the imports) if you need to link in external libs.
you need to at least specify the lib name if it's on the linker's
search path or provide the
Georg Wrede wrote:
Yigal Chripun wrote:
What I was saying was not specific for DWT but rather that _any_
reasonably big project will use such a system and it's simply not
practical to do otherwise. how would you handle a project with a
hundred files that takes 30 min. to compile without any
Yigal Chripun wrote:
Last thing, basing your arguments on history is flawed. the Micro-Kernel
idea got the same treatment after the failures in the 80's (Mach and
co.) but nowadays this idea was revived and there are already several
million cellphones that run an OS built on the L4
Yigal Chripun yigal...@gmail.com wrote in message
news:gv5dpn$2oe...@digitalmars.com...
I think Nemerle provies this - the constructs in Nemerle for the Macro
system are very simple and intuitive. you only have one extra syntax
feature, the [ ]. think of D's CTFE only much more extended in
Georg Wrede georg.wr...@iki.fi wrote in message
news:gv4t8t$1r4...@digitalmars.com...
Nick Sabalausky wrote:
Suppose (purely hypothetically) that the .NET assembly system were
changed to allow the source for a D/C++ style of source-level template to
be embedded into the assembly. Then
Hello Yigal,
BCS wrote:
It is my strongly held opinion that the primary argument for dlls and
friends, code sharing, is attempting to solve a completely
intractable problem. As soon as you bring in versioning, installers
and uninstallers, the problem becomes flat out impossible to solve.
(the
Hello Rainer,
My favorite deployment system is the application bundle under OS X.
It's a directory that looks like a file. Beneath the covers it has
frameworks and configuration files and multiple executables and all
that
crap, but to the user, it looks like a single file. You can copy it,
Nick Sabalausky wrote:
Christopher Wright dhase...@gmail.com wrote in message
news:gv29vn$7a...@digitalmars.com...
Nick Sabalausky wrote:
Christopher Wright dhase...@gmail.com wrote in message
news:gv0p4e$uv...@digitalmars.com...
Nick Sabalausky wrote:
I can see certain potential benefits to
On Wed, 20 May 2009 23:40:54 -0400, Nick Sabalausky a...@a.a wrote:
Christopher Wright dhase...@gmail.com wrote in message
news:gv29vn$7a...@digitalmars.com...
Nick Sabalausky wrote:
Christopher Wright dhase...@gmail.com wrote in message
news:gv0p4e$uv...@digitalmars.com...
Nick Sabalausky
BCS wrote:
in C# you almost never compile each source file separately, rather you
compile a bunch of sources into an assembly all at once and you provide
the list of other assemblies your code depends on. so the dependency is
on the package level rather than on the file level. this make so much
Nick Sabalausky wrote:
Maybe this is naive, but what about an AST-level template/generic? Couldn't
that provide for the best of both worlds?
For instance, suppose (purely hypothetically) that the .NET assembly system
were changed to allow the source for a D/C++ style of source-level
Yigal Chripun wrote:
Nick Sabalausky wrote:
I suppose that might make reverse-engineering easier which MS might
not like, but I'm not suggesting this as something that MS should like
or should even do, but rather suggesting it as (business issues
completely aside) something that would
Reply to Yigal,
BCS wrote:
in C# you almost never compile each source file separately, rather
you compile a bunch of sources into an assembly all at once and you
provide the list of other assemblies your code depends on. so the
dependency is on the package level rather than on the file level.
BCS wrote:
Reply to Yigal,
BCS wrote:
in C# you almost never compile each source file separately, rather
you compile a bunch of sources into an assembly all at once and you
provide the list of other assemblies your code depends on. so the
dependency is on the package level rather than on the
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
Before I got into D, I was working on Enki. Enki was my own programming
language and of course made D look like a piece of crap. In Enki, you
had only very few primitives related to macro expansion, and you could
construct all
On Thu, 21 May 2009 23:07:32 +0400, BCS a...@pathlink.com wrote:
Reply to Yigal,
BCS wrote:
Reply to Yigal,
if you compile each file separately than you parse all 4 files for
each object file which is completely redundant and makes little
sense since you'll need to recompile all of them
dsimcha wrote:
Bringing this analogy back to language design, if you make a language very
highly
configurable and don't provide good defaults, the barrier to entry will just be
too high. If people have to understand a whole bunch of intricacies of the
macro
system to do anything more complex
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:gv3ubr$2u...@digitalmars.com...
Yigal Chripun wrote:
Nemerle's interesting, but it has its own issues. The largest one is that
it will have to beat history: languages with configurable syntax have
failed in droves in
Nick Sabalausky wrote:
There are many possible reasons for a failed language's failure. One of the
biggest is lack of visibility. Who has ever heard of IMP72? Sure, that lack
of visibility could have been because people hated that particular aspect of
the language, but it could also have been
Reply to Denis,
I assert that very rare that a programs NEEDS to use a DLL/so/DDL type
of system. The only unavoidable reasons to use them that I see are:
1) you are forced to use code that can't be had at compile time (rare
outside of plugins and they don't count because they are not your
Nick Sabalausky wrote:
Suppose (purely hypothetically) that the .NET assembly system
were changed to allow the source for a D/C++ style of source-level template
to be embedded into the assembly. Then they'd be able to do D/C++ style
source-level template/code-generation. Right?
I assume,
BCS wrote:
I assert that very rare that a programs NEEDS to use a DLL/so/DDL type
of system. The only unavoidable reasons to use them that I see are:
1) you are forced to use code that can't be had at compile time (rare
outside of plugins and they don't count because they are not your code)
Yigal Chripun wrote:
What I was saying was not specific for DWT but rather that _any_
reasonably big project will use such a system and it's simply not
practical to do otherwise. how would you handle a project with a hundred
files that takes 30 min. to compile without any tool whatsoever
Andrei Alexandrescu wrote:
Yigal Chripun wrote:
Nick Sabalausky wrote:
I suppose that might make reverse-engineering easier which MS might
not like, but I'm not suggesting this as something that MS should
like or should even do, but rather suggesting it as (business issues
completely aside)
Yigal Chripun wrote:
just so you'd understand the scale I'm talking about - our largest
executable is 1.5 Gigs in size.
How is 1.5 GB of dlls better than a 1.5 GB executable? (And don't
forget, removing dead code across dll boundaries is a lot more difficult
than removing it within a single
Lutger wrote:
Yigal Chripun wrote:
...
IMO, designing the language to support this better work-flow is a good
decision made by MS, and D should follow it instead of trying to get
away without an IDE.
I'm not sure about this. D is designed to be easier to parse than C++
(but that's saying
Andrei Alexandrescu wrote:
...
What the heck do you need generics for when you have real templates? To me,
generics seem like just a lame excuse for templates.
I agree. Then, templates aren't easy to implement and they were
understandably already busy implementing the using statement.
Andrei Alexandrescu wrote:
...
I've repeatedly failed to figure out the coolness of C#, and would
appreciate a few pointers. Or references. Or delegates :o).
It's not in the language.
C# only has to do 'better' than C++ and Java to be cool and in that it
succeeds: Besides many smaller
On Wed, 20 May 2009 17:31:14 +1200, Jarrett Billingsley
jarrett.billings...@gmail.com wrote:
Just, uh, wow. Please dude, read up on this stuff first.
This thread turned into a java vs .net argument. I'm sorry but I don't
know the details of the JVM's just in time compiler. The virtual
BCS Wrote:
smaller object code? OTOH a good implementation will noice when I can fold
together several template expansions
That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.
Kagamin wrote:
BCS Wrote:
smaller object code? OTOH a good implementation will noice when I can fold
together several template expansions
That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.
They're not always binary-incompatible.
On Wed, 20 May 2009 13:09:37 +0400, Kagamin s...@here.lot wrote:
BCS Wrote:
smaller object code? OTOH a good implementation will noice when I can
fold
together several template expansions
That's the difference. You can't fold templates because they're binary
incompatible as opposite
Lutger lutger.blijdest...@gmail.com wrote in message
news:gv090o$22...@digitalmars.com...
Andrei Alexandrescu wrote:
...
What the heck do you need generics for when you have real templates? To
me,
generics seem like just a lame excuse for templates.
I agree. Then, templates aren't easy
Denis Koroskin wrote:
On Wed, 20 May 2009 13:09:37 +0400, Kagamin s...@here.lot wrote:
BCS Wrote:
smaller object code? OTOH a good implementation will noice when I can
fold
together several template expansions
That's the difference. You can't fold templates because they're binary
dsimcha escribió:
== Quote from Christopher Wright (dhase...@gmail.com)'s article
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:gus0lu$1sm...@digitalmars.com...
I've repeatedly failed to figure out the coolness of C#, and would
appreciate a
Ary Borenszweig:
That's why generics doesn't suck: if there's something wrong in them,
the compiler tells you in compile-time. In D, you get the errors only
when instantiating that template.
It's just like in dynamic languages, you need to unittest them a lot :-)
So having a static throws()
Nick Sabalausky wrote:
I can see certain potential benefits to the general way C# does generics,
but until the old (and I do mean old) issue of There's an IComparable, so
why the hell won't MS give us an IArithmetic so we can actually use
arithmetic operators on generic code? gets fixed (and
Frits van Bommel:
To do the latter transformation, the pass would need to be reimplemented to
run
when the code is closer to machine code.
Can't this feature be asked to the LLVM developers?
Bye,
bearophile
dsimcha wrote:
== Quote from Christopher Wright (dhase...@gmail.com)'s article
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:gus0lu$1sm...@digitalmars.com...
I've repeatedly failed to figure out the coolness of C#, and would
appreciate a few
bearophile wrote:
Frits van Bommel:
To do the latter transformation, the pass would need to be reimplemented to run
when the code is closer to machine code.
Can't this feature be asked to the LLVM developers?
Sure, feel free to file a feature request:
== Quote from Ary Borenszweig (a...@esperanto.org.ar)'s article
dsimcha escribió:
== Quote from Christopher Wright (dhase...@gmail.com)'s article
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:gus0lu$1sm...@digitalmars.com...
I've
Lutger wrote:
Andrei Alexandrescu wrote:
...
What the heck do you need generics for when you have real templates? To me,
generics seem like just a lame excuse for templates.
I agree. Then, templates aren't easy to implement and they were
understandably already busy implementing the using
Kagamin wrote:
Frits van Bommel Wrote:
That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.
They're not always binary-incompatible. For instance, if a template only works
with pointers or references (this includes object references) to
Frits van Bommel Wrote:
That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.
They're not always binary-incompatible. For instance, if a template only
works
with pointers or references (this includes object references) to
Christopher Wright dhase...@gmail.com wrote in message
news:gv0p4e$uv...@digitalmars.com...
Nick Sabalausky wrote:
I can see certain potential benefits to the general way C# does generics,
but until the old (and I do mean old) issue of There's an IComparable,
so why the hell won't MS give
BCS wrote:
minor point; I said you have to give the compiler all the source files.
You might not actually nned to compile them all, but without some
external meta data, it still needs to be handled the full because it
can't find them on it's own. And at that point you might as well compile
Andrei Alexandrescu wrote:
Lutger wrote:
Andrei Alexandrescu wrote:
...
What the heck do you need generics for when you have real
templates? To me,
generics seem like just a lame excuse for templates.
I agree. Then, templates aren't easy to implement and they were
understandably already
Yigal Chripun wrote:
I think you miss the point here.
Generics and code generation are two separate and orthogonal features
that where conflated together by C++.
It's kind of odd, then, that for example the Generative Programming book
(http://www.generative-programming.org) chose to treat
== Quote from Yigal Chripun (yigal...@gmail.com)'s article
Andrei Alexandrescu wrote:
Lutger wrote:
Andrei Alexandrescu wrote:
...
What the heck do you need generics for when you have real
templates? To me,
generics seem like just a lame excuse for templates.
I agree. Then,
dsimcha wrote:
Not sure I agree. C++ templates were probably intended to be something like
generics initially and became Turing-complete almost by accident.
That is factually correct. It was quite a hubbub on the C++
standardization committee when Erwin Unruh wrote a C++ program that
wrote
dsimcha wrote:
== Quote from Ary Borenszweig (a...@esperanto.org.ar)'s article
dsimcha escribió:
== Quote from Christopher Wright (dhase...@gmail.com)'s article
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:gus0lu$1sm...@digitalmars.com...
Reply to Yigal,
D templates provide mostly cosmetic changes to this.
If you think D's templates are C++'s template with a few cosmetic changes
than you aren't paying attention.
A few cosmetic changes aren't going to allow 1.4MB of c++ header files to
be anywhere near duplicated in 2000
Reply to Yigal,
BCS wrote:
minor point; I said you have to give the compiler all the source
files. You might not actually nned to compile them all, but without
some external meta data, it still needs to be handled the full
because it can't find them on it's own. And at that point you might
as
On Wed, May 20, 2009 at 1:09 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Yigal Chripun wrote:
I think you miss the point here.
Generics and code generation are two separate and orthogonal features that
where conflated together by C++.
It's kind of odd, then, that for
Nick Sabalausky wrote:
Christopher Wright dhase...@gmail.com wrote in message
news:gv0p4e$uv...@digitalmars.com...
Nick Sabalausky wrote:
I can see certain potential benefits to the general way C# does generics,
but until the old (and I do mean old) issue of There's an IComparable,
so why the
Christopher Wright dhase...@gmail.com wrote in message
news:gv29vn$7a...@digitalmars.com...
Nick Sabalausky wrote:
Christopher Wright dhase...@gmail.com wrote in message
news:gv0p4e$uv...@digitalmars.com...
Nick Sabalausky wrote:
I can see certain potential benefits to the general way C#
Bill Baxter wbax...@gmail.com wrote in message
news:mailman.151.1242855932.13405.digitalmar...@puremagic.com...
On Wed, May 20, 2009 at 1:09 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Yigal Chripun wrote:
I think you miss the point here.
Generics and code generation are
Nick Sabalausky wrote:
...
Maybe this is naive, but what about an AST-level template/generic? Couldn't
that provide for the best of both worlds?
For instance, suppose (purely hypothetically) that the .NET assembly system
were changed to allow the source for a D/C++ style of
Yigal Chripun wrote:
oh, I forgot my last point:
for C link-time compatibility you need to be able to _read_ C object
files and link them to your executable. you gain little from the ability
to _write_ object files.
You can transitivity. Two compilers for different languages that both
BCS wrote:
one other thing, this thread discusses also the VS project files. This
is completely irrelevant. those XML files are VS specific and their
complexity is MS' problem. Nothing prevents a developer from using
different build tools like make, rake or scons with their C# sources
since VS
Rainer Deyke wrote:
Yigal Chripun wrote:
oh, I forgot my last point:
for C link-time compatibility you need to be able to _read_ C object
files and link them to your executable. you gain little from the ability
to _write_ object files.
You can transitivity. Two compilers for different
Yigal Chripun wrote:
...
IMO, designing the language to support this better work-flow is a good
decision made by MS, and D should follow it instead of trying to get
away without an IDE.
I'm not sure about this. D is designed to be easier to parse than C++
(but that's saying nothing) to
BCS wrote:
...
all LINQ is is a set of standard nameing conventions and sugar. I Add a
Where
function to some SQL tabel object and you get the above as well.
...
Not really, LINQ is 'sugar' for the underlying libraries that implements
querying. Instead of
calling it just sugar, it is
Frits van Bommel escribió:
Ary Borenszweig wrote:
Frits van Bommel wrote:
Jacob Carlborg wrote:
Daniel Keep wrote:
Actually, Descent isn't perfect, either. For example, it mandates
that
cases in a switch MUST be aligned with the braces. What's more fun is
that you can't override it until
Yigal Chripun wrote:
Rainer Deyke wrote:
...
If you can read and write compatible library files, you don't need to
read or write compatible object files, since library files can take the
place of object files.
that's even better. just allow 2-way usage of C libs and that's it. no
need
On Tue, 19 May 2009 08:56:59 +1200, BCS a...@pathlink.com wrote:
VS/MS/etc is a for profit ecosystem. They assume that your system and
software is paid for by your boss and he's spending 10-20 time that much
on your paycheck so who cares. At least that's the impression I get.
I think
and the .net cil is a genious idea. The most succefull compilers are the
ones that recognize that there is multiple languages, multiple
archictectures and that there should be something in the middle. CIL
just leaves it in the middle code until the last minute. MS may not do
the best operating
Reply to Daniel,
Yigal Chripun wrote:
BCS wrote:
one other thing, this thread discusses also the VS project files.
This is completely irrelevant. those XML files are VS specific and
their complexity is MS' problem. Nothing prevents a developer from
using different build tools like make,
Reply to Lutger,
BCS wrote:
...
all LINQ is is a set of standard nameing conventions and sugar. I Add
a Where function to some SQL tabel object and you get the above as
well.
...
Not really, LINQ is 'sugar' for the underlying libraries that
As far as language features go, I'm even less
BCS wrote:
Reply to Daniel,
Yigal Chripun wrote:
BCS wrote:
one other thing, this thread discusses also the VS project files.
This is completely irrelevant. those XML files are VS specific and
their complexity is MS' problem. Nothing prevents a developer from
using different build tools
Reply to Yigal,
BCS wrote:
Reply to Daniel,
Yigal Chripun wrote:
BCS wrote:
one other thing, this thread discusses also the VS project files.
This is completely irrelevant. those XML files are VS specific
and their complexity is MS' problem. Nothing prevents a developer
from using
Georg Wrede wrote:
In the Good Old Days (when it was usual for an average programmer to
write parts of the code in ASM (that was the time before the late
eighties -- be it Basic, Pascal, or even C, some parts had to be done in
ASM to help a bearable user experience when the mainframes had less
Christopher Wright wrote:
I really like IDEs. They let me think less when creating code.
It wouldn't be hard to do a competent IDE for D. After all, D is
designed to make that job easy.
Walter Bright escribió:
Christopher Wright wrote:
I really like IDEs. They let me think less when creating code.
It wouldn't be hard to do a competent IDE for D. After all, D is
designed to make that job easy.
Like, for example, if you have this:
---
char[] someFunction(char[] name) {
Walter Bright:
The 6502 is an 8 bit processor, the 8088 is 16 bits. All 8 bit
processors were a terrible fit for C, which was designed for 16 bit
CPUs. Everyone who coded professional apps for the 6502, 6800, 8080 and
Z80 (all 8 bit CPUs) wrote in assembler. (Including myself.)
Forth
Ary Borenszweig wrote:
Do you really think implementing a *good* IDE for D is easy now? :-P
(of course Descent works in this case, but just because it has the full
dmdfe in it... so basically a good IDE will need to be able to do CTFE,
instantiante templates, etc., and all of those things are
bearophile wrote:
Forth interpreters can be very small, it's a very flexible language,
you can metaprogram it almost as Lisp, and if implemented well it can
be efficient (surely more than interpreter Basic, but less than
handwritten asm. You can have an optimizing Forth in probably less
than 4-5
Walter Bright escribió:
Ary Borenszweig wrote:
Do you really think implementing a *good* IDE for D is easy now? :-P
(of course Descent works in this case, but just because it has the
full dmdfe in it... so basically a good IDE will need to be able to do
CTFE, instantiante templates, etc.,
Walter Bright wrote:
Georg Wrede wrote:
In the Good Old Days (when it was usual for an average programmer to
write parts of the code in ASM (that was the time before the late
eighties -- be it Basic, Pascal, or even C, some parts had to be done
in ASM to help a bearable user experience when
Reply to Georg,
I wonder how a seasoned template author would describe what the most
welcome help would be when writing serious templates?
Breakpoint debugging of template explanation. Pick a template, feed it
values and see (as in syntax highlighting and foreach unrolling) what happens.
On Tue, 19 May 2009 16:09:54 -0700, Walter Bright wrote:
bearophile wrote:
Forth interpreters can be very small, it's a very flexible language,
you can metaprogram it almost as Lisp, and if implemented well it can
be efficient (surely more than interpreter Basic, but less than
handwritten
BCS wrote:
Oh and auto complete that works with meta but doesn't fall over on it's
side twiching with larger systems.
:-) It's getting better, slowly.
Hello Robert,
BCS wrote:
Oh and auto complete that works with meta but doesn't fall over on
it's side twiching with larger systems.
:-) It's getting better, slowly.
I can get you some test cases if you want... :-)
Not even this book cover could save Forth!
http://www.globalnerdy.com/2007/09/14/reimagining-programming-book-covers/
Walter Bright wrote:
Not even this book cover could save Forth!
http://www.globalnerdy.com/2007/09/14/reimagining-programming-book-covers/
Hehe...
And of course the Ruby book has the obligatory distasteful sexual
reference.
Only today I was reading another book on Rails and within the
Steven Schveighoffer schvei...@yahoo.com wrote in message
news:op.ut4vynx5eav...@steves.networkengines.com...
The docs are reasonable once you figure out how they are laid out.
I find the docs to be so slow as to be almost unusable. F*(*^*%* AJAX.
Hello Nick,
If Java has gotten so fast as many
people claim, why is Eclipse still such a sluggish POS?).
for the same reason that anything is slow, people more than make up for any
gains in perf with more features (and shoddy code)
== Quote from Christopher Wright (dhase...@gmail.com)'s article
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:gus0lu$1sm...@digitalmars.com...
I've repeatedly failed to figure out the coolness of C#, and would
appreciate a few pointers.
grauzone wrote:
and the .net cil is a genious idea. The most succefull compilers are
the ones that recognize that there is multiple languages, multiple
archictectures and that there should be something in the middle. CIL
just leaves it in the middle code until the last minute. MS may not do
dsimcha wrote:
== Quote from Christopher Wright (dhase...@gmail.com)'s article
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:gus0lu$1sm...@digitalmars.com...
I've repeatedly failed to figure out the coolness of C#, and would
appreciate a few
1 - 100 of 163 matches
Mail list logo
