Earlier quoted context omitted.
There's been some criticism of Microsoft's "Community Promise", such as this: http://techrights.org/2009/07/09/community-promise-sham/ and http://www.fsf.org/news/2009-07-mscp-mono and of Mono in general: http://www.fsf.org/news/dont-depend-on-mono
You lost all credibility by citing techrights (AKA boycott novell).
I finally understand why I'm not allowed to use Lisp
31–40 of 121 posts
Re: I finally understand why I'm not allowed to use Lisp
#32Earlier quoted context omitted.
There's been some criticism of Microsoft's "Community Promise", such as this: http://techrights.org/2009/07/09/community-promise-sham/ and http://www.fsf.org/news/2009-07-mscp-mono and of Mono in general: http://www.fsf.org/news/dont-depend-on-mono
> techrights.org That's where I stopped reading, but I'll say this: Nowhere in the FSF's critique of the MCP is it mentioned whether or not the promise itself is legally binding. From a bunch of people who are supposed to be legal experts. What does that tell you?
But, as far as that particular issue is concerned, as the techrights article points out,
"It may become legally binding ... if used as a challenge in court. But of course it does actually need to be tested in court /first/."
Re: I finally understand why I'm not allowed to use Lisp
#33What is so hard about this??? //assume some sorta IEnumerable derivitive IEnumerable bar = new IEnumerable() { obj1, obj2, obj3, obj4, ...};
var accumulator = bar.TakeWhile(x => x.property == someValue);
but then I saw the .NET 2.0 timeframe.
But even with .NET 2 you had generics which makes things pretty easy. But then again, he/she is ranting so I should just ignore him/her.
It doesn't matter what language you are using, if you cant write something that is legible to solve the problem, think about it more.
Re: I finally understand why I'm not allowed to use Lisp
#34Earlier quoted context omitted.
As soon as I read that I looked for the date of the post. May, 2007. This is before C# 3.0 was released and chances are he was even using 1.0 based on impressions from his boss. C# isn't half bad now, but back then, I agree it was fairly crummy.
[deleted]
Re: I finally understand why I'm not allowed to use Lisp
#35I find nothing interesting in the original post to be honest. Just somebody that has a superficial impression about C# is complaining. Even the first 25 comments that I read are of no particular interest. Meta: I wildly guess the HN post gets all the upvotes because initally people think that it will be about a google employee not allowed to use Lisp in google.
The article I read was about someone complaining about not being allowed to use all the features in the language selected for the project.
Re: I finally understand why I'm not allowed to use Lisp
#36Earlier quoted context omitted.
For me type inference changes the picture, since it reduces the duplication you see throughout Java-style statically typed code, but doesn't give up all the benefits.
The main thing that make programming in statically typed languages painful isn't the additional type declarations (which, as you rightly point out, need not even exist in languages that do competent type inference), but with the constant need to wrestle with the type system to get your code to compile at all. This is made doubly painful by the incredibly obtuse error messages spat out by some compilers, like: This ex…
error: conversion from std::_Rb_tree_const_iterator, std::allocator >,
std::basic_string, std::allocator > > >
to non-scalar type std::_Rb_tree_iterator, std::allocator >,
std::basic_string, std::allocator > > >
requestedRe: I finally understand why I'm not allowed to use Lisp
#37Earlier quoted context omitted.
Agreed. I would choose Python over C# for my own projects any day. However, I can't comprehend the senseless hatred that people have for C#. It is a nicer language than Java (imo) and it has very good performance. Furthermore, due to Mono, C# is no longer a closed platform.
Re Mono: Microsoft is not suing Google for patents on operating systems but instead pressures the handset manufacturers using Android. Is there a guarantee that a customer can use Mono for commercial applications, without a shake down from Microsoft?
1. There is stuff covered by the ECMA/ISO standards. This is covered by the Microsoft Community Promise, which is legally binding. This stuff is safe from Microsoft.
2. There is a lot of .NET stuff that Microsoft has released under the Apache 2 license, which includes a patent pledge. If any of this stuff is implemented in Mono, it is safe.
3. There is stuff in .NET that is not covered by the standards, and has not been released by Microsoft under a license that includes a patent pledge. Mono has independent implementations of the interfaces of some of these things. There is no Microsoft patent pledge covering these parts, and Microsoft may have patents on their own implementations. These patents would cover specific methods used in the implementation, not the interface.
The risk from #3 is small. Most important, it is about the same as the risk if you use that functionality in a non-Mono system. For example, I believe that there is an XML parsing library included in category #3. If Microsoft has a patent covering some particular technique of implementing an XML parser, there is no reason to believe that the people who implemented Mono's XML handling are any more likely to have infringed it than the people who implemented Java's XML handling, or Ruby's XML handling, or Python's XML handling, and so on.
Also, most of the things in #3 are things specifically related to Windows programming, so you'll only find them in .NET programs that were written for Windows. If you are writing for Linux, you don't need those things. Even if you want your programs to run on both Windows and Linux, you can do that without using the category #3 stuff. For instance, instead of using WinForms, use GTK#.
If Microsoft did decide to sue someone over their patents that cover the category #3 items that aren't Windows-specific, it is doubtful they would go after Mono. Microsoft has done enough to support and encourage the development of Mono that they would have a big estoppel problem to surmount if they wanted to sue over Mono. It would make a lot more sense to sue over Java or Python, where they would not face the estoppel issues. Remember, as I noted earlier, the category #3 patents are as likely to be infringed by those as Mono.
Re: I finally understand why I'm not allowed to use Lisp
#38Re: I finally understand why I'm not allowed to use Lisp
#39OOOH I was so wanting to tell the OP What is so hard about this??? //assume some sorta IEnumerable derivitive IEnumerable bar = new IEnumerable () { obj1, obj2, obj3, obj4, ...}; var accumulator = bar.TakeWhile(x => x.property == someValue); but then I saw the .NET 2.0 timeframe. But even with .NET 2 you had generics which makes things pretty easy. But then again, he/she is ranting so I should just ignore him/her. It…
Re: I finally understand why I'm not allowed to use Lisp
#40Kudos to his manager for actually looking at the code and recognizing the problem. Maintainable code is extremely important. Just keep your code simple. Adding another layer of abstraction instead of writing a simple and readable loop (if the language doesn't have accumulators) is not a good solution. I've seen this too many times. Smart developers write complex code, just because they can (and often it does make it…
In the majority of the cases however you deal with managers who lost understanding of anything but simple language constructs because all they did since becoming managers is management and no code development at all. At some point they start rejecting everything they don't understand. They justify their position by arguments of code clarity and maintainability. But they are misguided. To recognize readable and maintainable code you actually need to practice programming continually.
I dealt with such managers. They would tell me that a dozen of simple code lines are unreadable because they saw a new keyword they don't understand. But they would accept a hundred of code lines that do the same thing in which they can recognize all keywords. They wouldn't care about what the code actually does, nor they would care about what it takes to parse a hundred lines of spaghetti code.
It always fascinated me that some managers think they understand developing code better than developers they manage. I've had the best experience with managers that trust their developers to make decisions and the worst experience with managers that try to micromanage.