Novell's Mono: Imitating a Failing Technology

Dr. Roy Schestowitz

2009-01-04 11:21:36 UTC
Modified: 2009-01-04 11:21:36 UTC

"Pearly Gates and Em-Ballmer
One promises you heaven and the other prepares you for the grave."

--Ray Noorda, Novell

NOVELL'S INFATUATION WITH .NET is a truly bizarre thing. Why would a company that was repeatedly betrayed (back-stabbed or illegally abused even) by Microsoft suddenly just follow its footsteps? As blunter authors would possibly ask, "what is Novell smokin'?" It's almost paradoxical.

To call Microsoft "a success" is to confuse ubiquity with technical merits. Among the many reasons that Microsoft 'succeeds', one must account for the illegal deeds and political manipulation.

4 days ago, a person who is cautious not to be seen as Microsoft hostile (which he is not) said with high confidence that "Microsoft is just not ready for the enterprise."

In my last post I had made some comments about the Microsoft Windows not being capable of enterprise high performance computing. In the comments (upon request) I had posted some details on the SCSI subsystem of the Operating System, talking of the scatter gather lists when sequential SCSI commands are being coalesced just prior to being sent to the SCSI-based media. I wanted to continue on that topic and focus specifically on the NTFS file system and why it too is not intended for enterprise class usage.

[...]

With these limitations well known, then why do we still try to deploy Microsoft Windows in environments it was not suited for? The answer is familiarity. Microsoft for the most part owns the client/end-user market and with that the end-user has gotten too familiar and too comfortable with its platform. In turn what was built for home (and to an extent small business) use has leaked into an environment where it is not ready for. Please understand that I am not trying to preach against Microsoft and attack them. As many others in the high performing server/storage industry I have come to understand where certain problems originate from and that includes the limitations of the Windows platform. If you, the reader, feel something different with Microsoft and their role in enterprise class computing please feel free to comment. I know that I may not always be correct in my viewpoints and if you can shed any additional light I would very grateful.

Also, based on this bit of news from CMSWire, Microsoft's current agenda is all too clear. It wants to become a necessary part -- or the stack rather -- of an already-successful but lesser advertised technology.

Despite the efforts Microsoft has made, there is still a high degree of animosity amongst those involved in open source projects towards the software company. For example, Microsoft has a no-charge version of SQL Server available, but it's rarely used in the open source world. This edition of SQL Server isn't fully open source -- perhaps, this is part of the issue.

Microsoft hopes to sway LAMP-based developers to use parts of the Windows web application platform for certain uses. LAMP developers are known to utilize particular technologies for different needs. For instance, sometimes a developer will use Perl for one application and PHP for another. Will a typical open source developer look Microsoft's way? Not until Microsoft establishes some credibility and trust within open source circles. Until this happens, most open source advocates are nervous, now knowing what Microsoft's true motives are.

Bearing all of this in mind, Novell's continues to just imitate Microsoft with Mono and other Microsoft-inspired technologies, turning a leading platform into 'cheap Windows'. Why is Novell doing this (if not just to empower its new ally, Microsoft, just like its strategy requires)?

We continues to be concerned whenever Mono tries to creep into KDE. In this 143^rd issue of KDE commit digest from Danny Allen (it's the latest one), C# makes yet another appearance:

Support for on-the-fly compilation of Plasma data engines with the C# language bindings.

The person who pushes Mono 2.0 into Ubuntu is also doing this to Debian GNU/Linux. DevX has this new article which even promotes it.

The Mono 2.0 Offerings for Debian GNU/Linux

Find out how much of the Mono 2.0 (and beyond) platform is available for Debian users who want up-to-date .NET compatibility.

Mono is not about better development; it's about turning GNU/Linux into "Windows for poor developers" (and users). There are many other issues. ⬆

"There is a substantive effort in open source to bring such an implementation of .Net to market, known as Mono and being driven by Novell, and one of the attributes of the agreement we made with Novell is that the intellectual property associated with that is available to Novell customers."

--Bob Muglia, Microsoft Senior Vice President

Jim Allchin on Novell

Comments

AlexH

2009-01-04 11:44:59

Mono is exactly about better development; that's why you completely fail to understand why it grows and why people write articles which promote it.

If you don't like the licensing situation around it for whatever reason, that's up to you. To deny the technical reality of why people are interested in it is a bit bizarre, though.
Roy Schestowitz

2009-01-04 11:49:09

If people require OOP, there is already Java, which is more advanced, GPL licensed, and not controlled by the company that calls Linux "Cancer".
AlexH

2009-01-04 12:25:24

By that measure they could also use C, C++, Python or any other language.

What Mono offers is a lot more than "OOP".
Roy Schestowitz

2009-01-04 12:30:22

Yes, I know, but I was referring to the framework as well. Java is a lot more mature than Mono and there is room for development in C, C++, and Python under different environments.
AlexH

2009-01-04 12:31:40

Sure, but that's kind of besides the point. There are technical advantages to Mono that you're not recognising which is entirely separate to whether or not you think it's safe to use.
Roy Schestowitz

2009-01-04 12:34:52

These empower a an unfriendly rival of Free software.
AlexH

2009-01-04 12:40:51

Which, as I keep saying, isn't a technical feature.

You simply don't understand why people find Mono interesting.
Roy Schestowitz

2009-01-04 12:44:04

That's besides many points they are rarely made aware of.
AlexH

2009-01-04 12:46:34

No, it isn't. The "Mono isn't really free" meme is something a lot of people don't agree with, including most distributions, and is a matter of opinion / faith.

The "Mono isn't technically interesting" meme is just factually inaccurate. I'm not saying it's better than anything else; I'm just saying there are obvious reasons why people will want to use it.
Roy Schestowitz

2009-01-04 12:51:22

That's steering back to old debates. Two key points:

* Mono makes Microsoft stronger * Microsoft has patents on .NET

I'll quote a comment from last night

Your contention about Darryl being a Microsoft plant is probably correct, only they are called "Technical Evangelists" by Microsoft. Microsoft's head of TE's recently did a "mea culpa" and spilled the beans on their activities: http://platformevangelism.spaces.live.com/blog/cns !37F174267DC274C!126.entry AND http://platformevangelism.spaces.live.com/blog/cns !37F174267DC274C!152.entry

"Darryl" could be the Darryn Dieken mentioned in that article. These and other admissions are also listed in the "The Plamondon Files" at http://cid-037f174267dc274c.skydrive.live.com/brow se.aspx/The%20Plamondon%20Files

In the anti-trust lawsuit, Comes vs. Microsoft, the same PDF files were combined into one file at: http://antitrust.slated.org/www.iowaconsumercase.o rg/011607/3000/PX03096.pdf BUT, it LACKS the eye opening PR *** that Microsoft used. For example, in "Evangelism is War!" PDF one page has a single sentence that says "Microsoft is for developers". The next page has the same sentence but with a circle and slash through it, and the next page says "Microsoft helps Microsoft!".

So, use Plamondon's PDFs.

One standout sentence in "Effective Evangelism!" is: "The field of battle is the software industry. Success is measured in shipping applications. Every line of code that is written to our standards is a small victory; every line of code that is written to any other standard, is a small defeat.".

Read that and think about MONO.... or about OOXML.
Roy Schestowitz

2009-01-04 12:53:18

The URLs got mangled when I pasted them. Read the original comment for the URLs in tact.
AlexH

2009-01-04 12:54:54

"Steering back to old debates"?!

Pardon me for addressing the article rather than your opinion....
Hunain

2009-01-04 13:25:19

This article is an insult to your readers' intelligence.

Mono clearly has many merits for development that set it apart from Mono. Alex points this out several times, and all you have to answer is your ideological chant of 'it EVIL'.

That is beside the point.

You write in hour headline 'a failing technology'. It isn't.

That's the fact, and you can't wipe it away by ideological chanting about its 'ethics'.
Hunain

2009-01-04 13:25:51

correction: "that set it apart from Java"
Roy Schestowitz

2009-01-04 14:01:10

The word "failing" refers to Microsoft technologies.
aeshna23

2009-01-04 14:13:44

This conversation is far too abstract. If "Mono clearly has many merits for development that set it apart from Java", then I'm sure someone can provide me a top five list of those merits.

And given the risks of Mono, shouldn't some developers improve some free software development tools to also have those merits?
Dan O'Brian

2009-01-04 14:23:14

Sure, I can list 5:

1) P/Invoke 2) Mono supports SIMD, Java does not (nor does MS's .NET) 3) .NET (and thus Mono) support structs (Java does not) 4) .NET has better generics than Java 5) Wider variety of language support for the .NET runtime than the JVM.

There are no doubt numerous others.
Dan O'Brian

2009-01-04 14:28:22

Here are some more technical improvements that .NET has over Java:

http://news.zdnet.com/2100-9595_22-129182.html
xISO_ZWT

2009-01-04 14:43:10

A while back, we were implementing a "Fabric", utilizing 4 Hitachi 9985, 10 IBM DS4400 which we replaced half way through with 4800, 12 Bladecenters, all using 'root boot' which MS said could not be done, 3 SUN 6140, using a combination of SAS-SATA, 1 SUN 5200 Net-attachment, controlled through Cisco 9920 and Brocade 48000.

Our problem was consistent with any NTFS DAS on the local serving appliance connected to the fabric. The issues were frequent when extras spindles were added as storage demand grew on said server. The most common being corrupt data due to MFT corruption.
Roy Schestowitz

2009-01-04 15:26:32

We sure attract a fair bit of .NET-savvy readers. That leaves me wondering.
Hunain

2009-01-04 15:51:39

Outrageous lying always does that for a website. Nothing to be proud of on your part.
Roy Schestowitz

2009-01-04 16:01:07

Show me where in this post I "lied".
xISO_ZWT

2009-01-04 16:07:34

One of our biggest problems is that of downsizing. Certified FC-architects & admins are picking up attrition due to removal of Win-admins. In our lab we're running win2k8, for clients; (7000.0.081212-1400_client_en-us_Ultimate, win-7_ultimate_en_b6956(win6.1beta)). This is just for proof-of-concept (MS reps have been here). Doesn't mean they'll go in production.

The level of 'disk-churning' and constant write-back alone drive you up the wall. This is unacceptable for use on SSD storage units we're implementing.
aeshna23

2009-01-04 16:20:52

Thanks Dan for answering. I'll look into these to the best of my non-developer ability. In my limited understanding I do wonder about the better generics of .NET. I have intellectual knowledge, though no practical experience, of generics. What exactly is more attractive about generics in .NET?

And I promise that this is the last outrageously technical question that I ask on this tread!
Dan O'Brian

2009-01-04 17:12:30

You should probably read the answers here:

http://stackoverflow.com/questions/355060/c-vs-java-generics

of special note is the following criticism of Java's generics implementation:

Java Implementation

Java Generics were originally designed so that the .class file format wouldn't need to be changed. This would have meant that Generics-using code could run unchanged on JDK 1.4.0 and earlier JDK versions.

However, the .class file format had to change anyway (for example, generics permits you to overload methods based solely on return type), but they didn't revisit the design of Java Generics, so Java Generics remains a compile-time feature based on Type Erasure.

You can find that at http://www.jprl.com/Blog/archive/development/2007/Aug-31.html (which is linked off of the stackoverflow link above).
AlexH

2009-01-04 17:13:03

@aeshna23: In general, Wikipedia's articles are pretty good. For example, on generics, .net implements them in the run-time for any language, whereas for Java they are a Java-the-language only feature, not a JVM feature.
aeshna23

2009-01-04 17:41:31

From what I read, the reason for the difference between .Net and Java in terms of generics is that Java chose to be backward compatible. Thus, the difference could be eliminated without too much hassle to the language itself, but there is all that old code.

And the existence of that all that old code does mean that .Net and Mono will be superior in some areas to Java. I do get the point of those that defend Mono here. But the larger point is how should developers of FOSS spend their efforts? I do believe that Microsoft will get around to asserting patent rights on Mono which could mean that all their efforts will be wasted. Also, there is the question of creativity. Perhaps, I'm overly romantic about the computer, but what I hope to see in FOSS is new ideas, exciting new ideas. I don't want to see FOSS developers creating a second rate version of Windows. I experience my hypocrisy about this in many ways. I'm not really helping FOSS at all. I'm a vegetarian, but I'll eat those fake meat burgers--despite feeling that I should refuse to the eat fake meat also.
Dan O'Brian

2009-01-04 17:56:57

We sure attract a fair bit of .NET-savvy readers. That leaves me wondering.

.NET is a pretty commonly used development platform. You'd realize this if you didn't attempt to ignore reality.
AlexH

2009-01-04 18:03:12

@aeshna23: if you look at the Mono project, I think you'll find there are a number of exciting free software innovations - Dan already mentioned one, Mono.SIMD, which is unparalleled (as far as I know) in any other system.

The "legal" questions are completely different from the technical ones, which is what I was saying earlier really. Having Mono be compatible with .net doesn't reduce the amount of innovation that can take place.
Hunain

2009-01-04 18:03:55

Very few of Mono could be hurt by MS patents, and those are clearly separated from the rest of the code (winforms). Working around the specific claims MS would theoretically make, would put MS back to square one. And even IF Mono had to forgo winforms, it would still be a great framework (arguably better than Java).

We just NEED a framework like Mono if we want to go on competing against what MS will do with .NET in the future. You cannot simply whip up a new framework to do that - Vala is an attempt at that, but it's just lagging years behind.
AlexH

2009-01-04 18:25:44

There is a strong argument that Mono and Java should be merged, though, to some greater or lesser extent.
The Mad Hatter

2009-01-04 18:29:39

Both Mono and Java are sad jokes.

True. Anything that uses a run time is a said joke, that costs processor cycles, and is not efficient. It is easier to program in Java or C#. But the costs are CPU cycles and power usage. Why is this important? Anyone hear of Global Warming? Right. CPU cycles and power usage mean wasted energy, wasted energy means more emissions from power plants.

Anyone using Mono, .NET, or Java is partially responsible for ice flows melting in the Arctic, and should be shot.
AlexH

2009-01-04 18:34:41

@Mad Hatter: that might be run for naive run times which interpret byte-code. Neither Java nor Mono do that; they compile to native code. In fact, for generic code where types are only known at run-time, they run faster than statically pre-compiled code.

The cost overhead of using a VM is very small these days, and the much more comprehensive libraries (of well-written and efficient algorithms) more than offsets those losses.
The Mad Hatter

2009-01-04 18:41:45

Horse manure. If it's not as efficient as machine language or straight Compiled C Code, it's not efficient, and shouldn't be used.

QED.
AlexH

2009-01-04 18:44:06

@Mad Hatter: demonstrably incorrect; a hand-coded machine code bubble sort won't outpace quicksort for non-trivial data even if it was written in BASIC.

Assuming that programmers will write the most optimal code at all times isn't a good assumption. That's why we have standard libraries and high-level languages.
aeshna23

2009-01-04 19:31:37

Mad Hatter, it's fine to articulate a long run goal of getting stuff programmed in C or something similar, but you should realize that the cost in getting there immediately is not worth paying. We still are searching for excellent ways to do an OS with the programs people ordinairely use. It's going to take a long time searching around in higher level languages before we start building something excellent from the ground up in lower level languages. Hopefully, code will exist to do most of the lower level programming for us when the time comes.

I also think you are going too far to make a global warming argument about computer use. Let's worry about the assholes who drive SUVs first. Anyway, I would go so far as to say that talk about global warming is a determint to the environment in that the real ecological problem we face is human overpopuation. Global warming is just a relative innocous issue that serves to keep quiet us about overpopulation. We certainly do not want to save the planet if it means making the Catholics and other religious lunatics slightly uncomforable about the nonsense their religion peddles.
Roy Schestowitz

2009-01-04 20:07:55

Performance depends on the code and the optimisations -- if any -- from the compiler/interpreter. You can also write machine code that's utterly bad and inefficient.
The Mad Hatter

2009-01-04 20:22:25

@AlexH

You are comparing apples to oranges. If you set out to write a Quick Sort, assuming that all implementations are compiled, and implementing it in:

Java C# C Assembler Basic

And also assuming that all are optimized by programmers with the same experience level, the Assembler routines should be the fastest, and use the least CPU cycles. Going further, assuming that you are running this under Microsoft Windows XP SP3, the second fastest implementation will be in Basic, the third fastest will be in C. Java and C# are the most inefficient.

Now I'm going to assume that you will freak when you read this, because you won't understand why Basic would be faster. It all depends on the compiler. The most effective and fastest Windows compiler that I know of is the Power Basic Console Compiler by Bob Zale. Bob is a genius at optimization, and even though Microsoft tried to screw his company, he still manages to produce programming products for Windows that make Microsoft programming products look like crap.

http://www.powerbasic.com/products/pbcc/

For C there's a couple of good choices, including Borlands C compiler, Microsoft's C compiler, and GNU C. While I'm no fan of Microsoft, their old C compiler is actually pretty good, probably their best product, a hell of a lot better than Windows or Office. It used to be fast and lean, though as of VC 2 you could see bloat starting to accumulate. Borlands C Console Compiler is damned nice. GNU C is also damned nice.

There isn't an equivalent to those available for Java or C# that I've seen, and in my opinion this will cripple Java and C#, as the world moves towards higher efficiency applications to reduce power usage.

@aeshna23

As to the argument about SUV's, don't be an idiot. That's like saying that it's OK to allow jaywalking on residential streets, just not on highways. You either work towards efficiency, or you don't. There's no middle ground.

Think about how AA works.
AlexH

2009-01-04 20:31:55

@Mad Hatter: No, I'm not comparing apples to oranges. For trivial applications, yes, assembly or something might be possible. For something even slightly non-trivial like a GUI app it becomes silly.

Saying Java is less efficient than C, for example, is again a vacuous comparison. You completely side-stepped my point about dynamic versus static compilation, where a Java program can effectively re-write itself while running to get the best native code. Not only would the C programmer have to pay excellent attention through the whole of any app they're writing to keep up with a VM like HotSpot, they would also have to best the hand-coded assembler in critical sections.

It's just not sensical to say "Java is inefficient".
Roy Schestowitz

2009-01-04 20:50:50

Speed of development counts too.
AlexH

2009-01-04 20:52:05

@Roy: precisely! It's no good if your C app is faster than your Java app if it takes tens of times longer to write.
aeshna23

2009-01-04 21:04:48

@Mad Hatter

It's simply mad to compare FOSS development to alcoholism--even for those few who are addicted to programming.

For me, it's just not OK to allow jaywalking on residential streets and forbid it on highways. I feel intense loathing for people who want to forbid jaywalking on residential streets. I hate them for all the utterly pointless, anal things that we are forced to do because of them. Rules should be applied reasonably and not with insane fanaticism.
Dan O'Brian

2009-01-04 21:34:21

The world isn't moving back to C and asm, the world is moving away from them. Java and C# are becoming more and more popular, not less.
The Mad Hatter

2009-01-04 22:10:58

@Dan O'Brian Just like the world moved to trading in derivatives based on sub prime mortgages? Yeah, right move.

@aeshna23 I didn't mention alcoholism - where did you get that from? As to jaywalking, the point is that you have to be consistent. Think about it. The small shit counts.

@AlexH Really? You don't think that the lack of a superb Java/C# compiler is an issue? Think back to the early days of Micros - the lack of a good C compiler held off general adoption of C as a programming language for years/

@Roy Schestowitz If it's a run once application, I agree. If it's going to be run by millions of people daily, I disagree completely.
G. Michaels

2009-01-04 22:13:26

Horse manure. If it’s not as efficient as machine language or straight Compiled C Code, it’s not efficient, and shouldn’t be used.

Ah, another canonical example of the type of "fan" this blog attracts.

"Programming is hard for me, it should be hard for everyone! And anyone who disagrees is an idiot!!"

I'll keep this in mind the next time I get a proposal for a J2EE inventory control app at my company. I'll send it back with a recommendation to code it entirely in x86 assembler.

Note: writer of this comment adds absolutely nothing but stalking and personal attacks against readers, as documented here.

Roy Schestowitz

2009-01-04 22:13:36

Google, which burns energy by the buckets, uses lots of Python and I doubt they mess about with OOP.

Dan O'Brian

2009-01-04 22:28:29

There's a lack of a good C# compiler? Says who?

Also note that w/ Mono, Mono will at runtime detect if the bytecode can be optimized using SIMD on the current architecture and use that instead of the less efficient instructions that GCC would have compiled the same logic to.

Dan O'Brian

2009-01-04 22:30:33

Roy: actually, Google very much do in fact use OOP. You can use OOP in Python.

Roy Schestowitz

2009-01-04 22:31:44

Ah, okay. I was thinking about Java, although they use it extensively (if not exclusively) in Android.

Dan O'Brian

2009-01-04 22:34:40

FWIW, everyone uses OOP these days.

Roy Schestowitz

2009-01-04 22:40:43

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

*YOU* are full of bullshit.





C++ is a horrible language. It's made more horrible by the fact that a lot 
of substandard programmers use it, to the point where it's much much 
easier to generate total and utter crap with it. Quite frankly, even if 
the choice of C were to do *nothing* but keep the C++ programmers out, 
that in itself would be a huge reason to use C.





In other words: the choice of C is the only sane choice. I know Miles 
Bader jokingly said "to piss you off", but it's actually true. I've come 
to the conclusion that any programmer that would prefer the project to be 
in C++ over C is likely a programmer that I really *would* prefer to piss 
off, so that he doesn't come and screw up any project I'm involved with.





C++ leads to really really bad design choices. You invariably start using 
the "nice" library features of the language like STL and Boost and other 
total and utter crap, that may "help" you program, but causes:





 - infinite amounts of pain when they don't work (and anybody who tells me 
   that STL and especially Boost are stable and portable is just so full 
   of BS that it's not even funny)





 - inefficient abstracted programming models where two years down the road 
   you notice that some abstraction wasn't very efficient, but now all 
   your code depends on all the nice object models around it, and you 
   cannot fix it without rewriting your app.





In other words, the only way to do good, efficient, and system-level and 
portable C++ ends up to limit yourself to all the things that are 
basically available in C. And limiting your project to C means that people 
don't screw that up, and also means that you get a lot of programmers that 
do actually understand low-level issues and don't screw things up with any 
idiotic "object model" crap.





So I'm sorry, but for something like git, where efficiency was a primary 
objective, the "advantages" of C++ is just a huge mistake. The fact that 
we also piss off people who cannot see that is just a big additional 
advantage.





If you want a VCS that is written in C++, go play with Monotone. Really. 
They use a "real database". They use "nice object-oriented libraries". 
They use "nice C++ abstractions". And quite frankly, as a result of all 
these design decisions that sound so appealing to some CS people, the end 
result is a horrible and unmaintainable mess.





But I'm sure you'd like it more than git.





			Linus

Dan O'Brian

2009-01-04 22:49:22

Even the Linux kernel uses some object oriented techniques in C. You don't need an OO language like C++ to do so.

Whenever you use a "context" struct in C, you are effectively using OOP.

Roy Schestowitz

2009-01-04 22:55:42

True, there are no fine lines in abstraction.

FWIW, I've never agreed with that view of Linus. It also drips vanity.

Jose_X

2009-01-05 01:06:34

>> It also drips vanity.

It drips as what he views as maximally efficient for his particular project. He isn't the only one thinking along those same lines, either.

Yes, the delivery of the message sounds vane.

***

Most languages have evolved techniques so that they can be used efficiently today (at least for various purposes). Usually when you improve the language a dash you give something up that would be of value in some areas.

FOSS is not like a typical business in-house project. It has the potential of having a lot of key code will be built with distributed costs while accessing overall a greater amount of resources (like eyeballs), eventually be refined by devs with a higher average level of skill, and be used/leveraged by a much larger group.

Not every app benefits from X and Y runtime support overhead.

Perhaps we should all program in some universal and extensible xml-based language system that has virtually unlimited room to add attributes, hints, nonprogramming metadata, inline speedups useful under some cases, etc. With suitable translators/viewers, that same file can be seen in and compiled from many different languages/frameworks (losing some capabilities depending on the mapping target chosen). Future improved frameworks can very easily use the same old source code (though work best after new tuning/tagging is created). We can all program using very high level concepts with lower level hints/implementations as we find time/need. Testing can be worked into the system as can almost anything one can think of (after designing the suitable xml tags/rules). Such an xml framework would not be designed without thought and be workable well into the future, but someone could probably do a good enough job. The xml "file format" can be grown at a different rate as the tools that support it/map from it. Eg, some hints may not be used my any framework for years.

Why not allow yourself maximal room for design and creativity?

Of course, even this will not be ideal for all cases.

Jose_X

2009-01-05 01:09:47

I'm aware that dotnet and java and others attempt to do to some degree what this hypothetical xml framework would do.

Dan O'Brian

2009-01-05 01:15:31

I'm not even sure what you were just going on about. It made absolutely no sense at all.

Roy Schestowitz

2009-01-05 01:19:10

I lost track as well, but I read it too quickly.

Jose_X

2009-01-05 01:22:00

I also want to add that you can simply pick a language/framework and then add everything you want to add to your app as some form of metadata within comments, in a separate file, or even as data within the app. You'd have to develop compile time and runtime support for all of this. People do this already to various nonstandard degrees to suit their tastes and the problem at hand. The key is in the details, in standardization where realistic, etc. Leveraging tools, formats, techniques, whenever this is possible is a Good Thing.

Jose_X

2009-01-05 01:23:18

Dan, that's ok. If you want to point to something specific go ahead. Otherwise ignore it.

Roy Schestowitz

2009-01-05 01:33:41

At second read I got the point.

Dan O'Brian

2009-01-05 03:06:40

it sounds like he's trying to create a straw man to me, but maybe I'm just not understanding correctly.

Novell's Mono: Imitating a Failing Technology

The Mono 2.0 Offerings for Debian GNU/Linux

Comments

Recent Techrights' Posts