Below are the most popular languages. If your favorite isn't below select other and comment what it is below.
Note: By voting for a language you are not up voting this poll. Please up vote this poll to keep it alive.
How do you convert to a string? Convert.ToString(). How about an integer? Knowing only that one, it's what you'd expect!
I also picked JavaScript because I am in a love affair with this weird little language. I also think it is one of the easiest languages to teach basic programming with (videos forthcoming).
The amount of time it takes to whip up a five-cent program with javascript without even leaving my browser, heck without even leaving this tab is just astounding to me even after all these years.
One thing I noticed though while writing this comment is that more than the language itself, the tools that I use while building things in the language are what really make them a pleasure to use. If I wasn't using Google Chrome's web developer tools I'd probably consider JavaScript to be a nightmarish corpse of a language that punishes the slightest of typos with a silent malicious grin, as code execution carries on as if A.blah = 5 and A.blsh = 5 were both equally worthy of existing to the JS compiler/interpreter. Only by the grace of tools is JS tame at all.
Also, I dread getting asked on my next interview "whats the one thing you don't like about your favorite language". I honestly can't think of anything off the top of my head. Granted, I've come across things that were frustrating at various times, but they never stick in my mind. I think that's a testament to how well the language has evolved.
That's easy. So many hacker types dismiss you as some sort of weirdo for favoring anything that came from Microsoft.
1) I dislike C#'s types; they're neither as strong and intelligent as a ML/Haskell language nor as convenient as a Python/Ruby family language.
2) I much prefer the sense of design displayed by Python and Ruby open source projects over C#. (Not that there aren't issues there!)
3) I hate Visual Studio. Nice debugger, crappy interface for writing code. Horrific user interface design for the most part. (At least back when I was writing C# back in 2009!)
4) I hate Windows. Linux and Mac are far more developer friendly. I hated dealing with Cygwin to get some sort of reasonable (crappy but tolerable) command line environment.
5) I love git. Until fairly recently, git was not available and stable on Windows. For it and for many other bits of software, windows is a second class citizen.
Shall I go on? Because I could. But I'll leave it at 5 for now.
Anyway, I don't think bash/zsh is so great, rather the tools that have grown around them for the last 20 years make them the best available option. Powershell may be nice, but it's got a long road to hoe.
It has a steep learning curve, as one needs to learn a new set of commands, but once you start getting it, it is great.
I just have two complaints with it: - the stupid ps1 extension; - commands are verbose when comparing with other shells
1. "Strong and intelligent"? "Convenient"?
2. "Sense of design"? My current side project includes a web scraper which uses the following open source projects: AutoMapper, CsvHelper, HtmlAgilityPack, Twitter Bootstrap, jQuery, Modernizer, Moq, NLog, MongoDB C# driver, PetaPoco database driver, Rx extensions, knockoutjs and structuremap. 8 of those are .NET specific. Because of their excellent design, I have probably no more than about 30 lines of code hooking up to them (where I use interfaces) and maybe no more than 100 lines of code total utilizing them directly. Yet they conceal YEARS worth of work I would have to do myself.
3. Have you ever used Resharper? I've never heard of anything equivalent on any platform for any IDE (except for IntelliJ, developed by the same company, Jetbrains).
4. I'm fine with Windows. I find both Linux and Mac less developer friendly. I'm fine hosting my services on Linux and interfacing with them from C#, though, because it's a great server operating system. I've been using computers for 20 years and I'm happy to be away from the command line 99% of the time. What do you like about it?
5. Git Extensions + Git Source Control Provider are a completely integrated and free Git experience on Windows.
Not a C# user, but few languages of the strength and intelligence of types in ML. Covariant arrays (which C# presumably adopted for the sake of Java programmers) moves an easy, and obvious, compile time type check to runtime. The type inferencing in C# is very weak relative to ML/Haskell. The type syntax is generally more lighweight in ML/Haskell as well. For example a function that takes a list of some type ('a) and returns the head of the list if it exists or None if it doesn't looks like:
val hd : 'a list -> 'a option
Of course, all if this works in unison with other type functionality that is far more lightweight in ML than C#. The function above is only really so succinct because I have powerful variant types and pattern matching on them. I think they go hand in hand because using an option-type is somewhat useless if I don't have something like pattern matching to access its state.
var firstNumber = numbers.FirstOrDefault();
Here's an implementation in C# that is a function on types T implementing the IList interface (rather than IEnumerable like LINQ does):
public static T Head<T>(this IList<T> list) {
return (list == null || list.Count == 0) ? null : list[0];
}
1. the 'option' function you have in your example. In reality, your 'option' is doing all the work I did above, which means that comparing the verbosity of your sample code to the C# equivalent of FirstOrDefault() is perfectly valid in my opinion :)
2. the explicit return type. This serves a valuable purpose in my opinion.
With your code, it's easy to break the hd function by changing the implementation to return a different type. You might not even notice the bug if the different type's implementation is close enough to the right one. I once had a bug like this in VB6 years ago: I changed a method to use an integer instead of a string, and VB's automatic type casting happily allowed the rest of my code to function... until in the middle of a demo I ran a function I hadn't tested and default value of 0 broke something expecting an empty string! My lesson: type inference can be dangerous.
It also makes refactoring a large project much more difficult in my opinion because there is no way to distinguish between specification and implementation. Consequently, changing your implementation runs the risk of breaking your specification without being informed.
There is a school of thought that says your unit tests should cover this aspect of the specification... but then all I'm doing is implementing explicit types in a roundabout way - let the compiler do that I say! That being said I don't know if ML/Haskell have 'interface specification' types to ward against this, where you need it (and everywhere else you get to save on verbosity)? That would be a nice improvement to C#: private methods can use extended type inference, anything public (including implementing an interface) need to be more explicit.
3. syntax: visibility (public), static modifier and return statement. This is a matter of personal preference. With Resharper in Visual Studio each of these words costs me 2 or 3 keystrokes, and if I like I can use templated code snippets to reduce that for any situation, so I'm not too bothered :)
> return (list.Count == 0) ? null : list[0];
Would the C# compiler catch it or would you not find out until runtime? An ML compiler would tell you that function is wrong.
What about using Head? If you have a list of integers, will the compiler let you do:
> Head(integer_list) + 2
An ML compiler won't, because it's not safe.
> This isn't strictly the same as what you described if "None" is different from "null".
It is, but the important thing to note is I had to specify that the function, 'hd', can return 'null', by wrapping it in the option type. 'null' is only a valid value for option types. If I write:
> val hd : 'a list -> 'a
I could not return 'null'/None, it simply isn't valid. And the compiler wouldn't let me.
> the 'option' function you have in your example
'option' is a type, not a function (I suppose you can make some high level argument that all types are functions over values or something, but not relevant here). And 'option' itself isn't really even a type, it requires a type variable, so "'a option" is a type where "'a" is replaced by a concrete type at some point. It's not doing the work you described above, it's actually defining a contract between me and users of hd and the compiler.
> With your code, it's easy to break the hd function by changing the implementation to return a different type. You might not even notice the bug if the different type's implementation is close enough to the right one.
No, it isn't actually. If I change the return type the compiler will not compile my code.
> I changed a method to use an integer instead of a string
This cannot happen in ML, the compiler won't compile it because an integer isn't a string. What you described is not type inference, it's dynamic typing. The only danger of type inferencing in ML is annoying type errors during compilation. I'm not sure you actually grok what type inferencing is.
> It also makes refactoring a large project much more difficult in my opinion because there is no way to distinguish between specification and implementation. Consequently, changing your implementation runs the risk of breaking your specification without being informed.
Actually, refactoring code in ML tends to be pretty easy. If you change the type of something the compiler won't compile your code, so you know instantly where you messed up and can fix it. You can construct code to make this not work, but in general that isn't the case. See https://ocaml.janestreet.com/?q=node/101
> let the compiler do that I say!
Exactly, and an ML compiler definitely does more of this than the C# compiler. At a cost, of course.
Your post has several statements which suggest you are ignorant of ML and type theory. If you're interested in learning more, check out Benjamin Pierce's book "Types and Programming Languages". Or just spend a weekend with Ocaml or Haskell and prepare for the compiler to frustrate you with it's strictness :)
I don't think it's far out to suggest these sorts of advantages, and I am 100% not interested in rehashing a flame war that's been had a thousand times over. Please allow that these are my judgements, and I hope you don't need to share them to see that many people feel that way.
2. That's nice? I found C# projects to have a poor sense of design. I'm not sure how you expect me to defend an aesthetic decision.
3. I'm glad you like Resharper? I didn't. I'm a vim guy.
4. I'm glad you like Windows? I don't. I see what you mean, as long as you stay in the MS womb, it's a cozy development environment. I tend to like open source software, and it lags behind very seriously in that department.
5. As I said, I last developed C# in 2009, and I thankfully haven't had to touch Windows since. I'm sure git is nice now, but I suspect that Windows is still a second class citizen for many software projects. Git is just the one that annoyed me most back then.
It seems to me that we simply have different aesthetic criteria.
You don't need to debase an otherwise great conversation with incendiary language like that.
I'm not going to go back and edit it, but I'll ask you to give me the benefit of the doubt that I meant it to be as as far from incendiary as possible.
So too does the command line! high five
I'm guessing you like to debug using print and the command prompt as well?
For most the world keeps on spinning, for some it stops in their youth. Sad.
Also, the homogeneity of the unix interface (pipes and utilities that uses them) means that you also have very powerful primitives to work with.
Proving the utility of the command line could benefit from a few full featured examples, but this would need a longer post that i'm in the mood of writing right now :)
With that said, you have a powerful administration programming language on windows called powershell. It's much better than bash by a lot of metrics. The way it's integrated into the system is not very good though. For example, the terminal client sucks, and the security system is way too complicated for casual use.
(Overall though, I agree that Linux and Mac give a better developer experience.)
http://www.victusspiritus.com/2011/10/30/an-elegant-ruby-scr...
Even better I would have an option type so that you never need to use null, ever.
-It's wordy. The var keyword was a step in the right direction, but there's still a lot of redundant type information, even compared to other statically typed languages like Go or F#.
-Legacy code. A lot of things that are concise and easy in C# 3.5+ were possible but hideous in older versions. Sadly, that code must still be maintained.
-Null handling. Like another commenter, I wish the language would help more with null values. I'd love an operator to do monadic null coalescing: var foo = thing1.thing2.thing3.bar; Sometimes I want foo to be null if any of the chained objects are null.
It's a pretty good language, though. I'm looking forward to the Roslyn API to the compiler: http://msdn.microsoft.com/en-us/hh500769
In fact, C# deals excellently with legacy code. While, unlike the JVM, .NET is not binary backward compatible (allowing some excellent language improvements that Java still has not managed to pull off), it is nearly (but not entirely) source code backward compatible. Sure, this allows to old code using old constructs to stay alive, but it works. That alone is pretty unique, especially if you see that nearly any other language either does not manage to move its community to the next version with breaking changes (Python 3, PHP 6) or has tons of compatibility issues every time something changes (Ruby, Scala), or simply is at a standstill (Java).
Having to deal with a DictionaryBase child class which was made before generics were added is way less of a deal than not being able to upgrade your software to the newest version of the language at all. Which is what would've happened if this was done like Scala. Or, if it was done like Java, we'd still be hacking DictionaryBase child classes.
I'd maintain that no language/platform deals with legacy code better than C#.
A lot of hosting environments like Google AppEngine still do not support Python 3. The "there's going to be no 2.8" PEP might help that, though. We can only hope.
In fact, the "big breakage" in Scala everyone loves to cite was the addition of better collections. Just like C# did in 2.0 and now finally drops the old non-generic ones with WinRT/Metro.
The reason it gets so much flack is that Java developers want _binary compatibility_, because that's what they are accustomed to and Scala gets often used by Java developers. Java developers would target the same criticism towards C# if it would run on the JVM.
I take the part on Scala back.
You can do a fair amount of relatively frictionless null handling with extension methods. If that helps.
This will work.
andand negates the need for an explicit null check on each property in a property lookup chain, which would normally be required to avoid a potential NoMethodError or NullReferenceException.
You can create something similar [2] to andand in C# if you are willing to do property lookups using lambda expressions.
- Events and properties aren't first-class, which is lame. I can't even easily get the "get" or "set" method of a property without either using reflection or making a wrapper lambda.
- No syntax sugar for tuples.
- No syntax sugar for destructuring anything. Come on now.
- The type system has big holes. For example, I still can't specify class Something<T> where T : new(T) (i.e. where a copy constructor exists on T.) And I can't specify class Something<T> where T : /* is a numeric type */.
- It would be nice if there were type inference on more things, like property and field types.
- All reference types are nullable which sucks.
For the simple case of say, destructuring a tuple, that could work well: a, b = ReturnsATuple(). But anything more general would just seem tacked onto the language.
But then again, tuples don't really fit well in C# either! Tuples are only useful if you don't have to declare their types, ever. Without full type inference, nothing is saved by using tuples over, say, an inline object.
I don't understand the significance of first class events, so I can't really comment on that. And as far as I know, delegates are first class now with the inclusion of lambdas.
All the suggestions on the list make sense, and many like them have been added over teh past few years. To me it seems that all of them except the 'reference types that are not nullable' one could be easily added without breaking backward compatibility.
In fact, I wouldn't be amazed if a C# 6 has sugar for tuples and destructuring assignments and the likes. It matches the language well (already got a type-inferencing compiler, already on the road to incorporating increasingly many functional programming ideas).
And, well, in code you can already say
var george = new Person();
Person george = new Person();
The only reason I see for not doing things like this is to avoid becoming the next C++, in which there's just too many features and things to understand.
sugared tuples and destructuring doesn't really fit. You'd have to make special case syntax for it and it would just feel bolted on to the language. Plus, tuples lose their usefulness if you have to declare its type to pass it between methods.
Though his first point about getters and setters does make sense, I didn't quite comprehend it the first time around.
I think it could be OK even without return type inference on methods. Imagine you could type this:
(int, bool) TryParse(string str) {
// do stuff
return (num, success);
}
But once you get over that mental hump of seeing a new in front, it really starts to make a lot of sense. A tuple could be considered a value type and treated similarly to int or string literals. Very cool.
By numeric type do you mean a type implementing numeric operations? I agree, it's weird they haven't just whacked an interface on that.
And when are we getting an "unless"? It's way more readable than "if (!(some complex condition))".
Oh and null coalescing with member support. "y = x != null ? x.prop : value" is way too verbose.
At least you have the option of out params. I have to use Java every day and the only real option is return classes.
And about numerical types, I agree that would be great to have a base class "Number" for double, int, etc. But meanwhile you can use this trick: http://stackoverflow.com/questions/3329576/generic-constrain...
And yet, working with C# is joyful.
- Events, i.e. the observer pattern, are indeed supported first class by way of the `event` keyword and BCL `Delegate` type. And the whole point of properties is to be syntactic sugar to hide implementation details by surfacing state accessors with field-like mechanics. If you need a quick and easy way to reference a "getter method", you're breaking the abstraction and shouldn't use properties. That's the trade off.
- The BCL provides multiple generic, high-performance `Tuple` types.
- Destructing. Memory management is handled by the GC, so what would destructing even mean? The `using` keyword along with BCL type `IDisposable` provides a very usable mechanism for releasing non-memory/unmanaged/OS resources.
- This is mostly valid. That said, `ICloneable` can get you most of the way w.r.t. the copy ctor. As far as the numeric generic, one is required to make do with type-specificity and method overrides, since the numeric types were written without generics in mind. Or you can implement your own numeric type system. Do that once and you can write numeric generics to your heart's desire.
- How could this work with auto-properties?
- Trivial to implement a `NonNull<T> where T : class`. But because of other language constructs (`??` operator) idiomatically `null` references are not considered the end of the world. Design by contract support in the BCL `Contract` type alleviates this as well.
edit: expanded property method explanation.
int a, b;
(a, b) = function_returning_array();- There are only properties, no fields or other stuff. This means you can replace a method with a constant easily, or add your own setter to a mutable property later without breaking source or binary compatibility.
- Tuples: (1, "Foo", 42.0)
- val (a,b) = (1,2). Also works with regexes, case classes, ... basically everything which has an `unapply` method.
- class Something[T : Numeric]
- Type inference everywhere, with the exception of method parameters (and recursive methods).
It also has one of the most powerful type systems, traits, everything-is-an-object, higher-order functions, higher-kinded types.
Caveat: Runs on the JVM. The .Net port hasn't been officially released, but is planned for the next release.
There is an introduction for C# developers, if you are interested: http://docs.scala-lang.org/tutorials/scala-for-csharp-progra...
On design alone, I would probably vote Clojure. The features and their rationale are very compelling.
Limited support in the open source ecosystem? Open source projects are reluctant to build on something that might infringe on an MS patent. That's what keeps me away from the language. To be fair, this is more an indictment of the patent system than C# itself.
C#'s answer for all of its missing features seems to be a generic class. Don't have tuples? We'll give you Tuple<T>. Don't have inline functions? We'll give you Func<T>. It feels very tacked on (especially Func).
() => { DoSomething(); }
No return value needed (compiles down to an Action<T> I think)
Which is an other crufty thing in C#: because Void/() is not a type (inherited from Java), it needs to have both `Func<Tn..., T>` and `Action<Tn...>` in order to handle functions-with-a-return-value and functions-without-a-return-value.
I fail to see the relation this has with my issue.
Func<int,int> fib = null;
fib = n => n > 1 ? fib(n - 1) + fib(n - 2) : n;
delegate Func<A,R> Recursive<A,R>(Recursive<A,R> r);
static Func<A, R> Y<A, R>(Func<Func<A, R>, Func<A, R>> f) {
Recursive<A, R> rec = r => a => f(r(r))(a);
return rec(rec);
}
Func<int,int> fib = Y<int,int>(f => n => n > 1 ? f(n - 1) + f(n - 2) : n);
For a language to be first class in .NET it needs to be able to do OO with the same semantics that the CLR has, otherwise you will have leaky abstractions all over the place.
They are intended to manipulate the abstract syntax tree of lambda expressions. A bit like macros.
You should only need to know about them if doing AST manipulations.
Also, it makes APIs incredibly discoverable. Not sure what a `IQueryable` provides?
IQueryable iq = null; iq.
(edit: formatting)
* Cmd+Tab to Chrome
* Cmd+L for location focus
* \IQueryable searches DuckDuckGo for IQueryable and takes me to first result
I get to use the editor I want (hint, not visual studio), and I know a lot more about IQueryable anyway and can continue poking around in the docs to learn more about the 'nearby' bits of the API.
I don't really want my editor to write code for me after only a fraction of the characters. I like writing code. I agree with Inufu, I feel like completion of more than, say, IQu[tab] is starting to show redundancy I'd prefer not to have in the first place.
"That doesn't sound all that good to me. Here's how I do it in multiple steps, in a different window!"
Do you see the problem here?
Those who don't understand UNIX are forever doomed to re-implement it - poorly. Which is the story of every IDE ever.
I spent years hating Java and embracing vim, but as I tried to shape my environment more, I grew increasingly frustrated. Finally, I was forced by necessity to use Eclipse and Maven with Java, and the lightbulb turned on for me.
Any language that takes 30-40% less code to do something for you is taking away some freedom. They're making convention easy but can make escaping it to be hard, or may slow down because of more dynamic-ness, or some other tradeoff. And there are many good tradeoffs to be had when creating programming languages, of course.
The deal with Java is that it is the pedant of languages. Half-answers and hand-waving to how objects interact (i.e. duck-typing) aren't good enough for it. This makes libraries or APIs very, very easy to reason about, because if it doesn't access to that information then that means that the library or API is broken or intentionally hiding those details from you. But on the other hand, it enforces a kind of light, but still present, agreement between classes on their relationships to each other.
The point at which your thoughts on IDE come into this is that because Java has a very rigid structure, it can make sweeping code changes at massive scale. This is something that, with shallower insight into the language, or without insight into the flow of code through a method (i.e. checking for dead code or invalid assignments), and so on, would take a massive number of man-hours to duplicate, or make use of the exact same code the IDEs themselves have written for the purpose (i.e. emacs and vim are capable of delegating certain functions to eclipse). Decoupling it in the UNIX way doesn't really make a whole lot of sense when everything is very interrelated in nature.
As well as generate, but given that some people think that if code can be generated, it should be done at runtime by the language instead, I don't want to argue this too hard in this reply. They're not wrong but they sure aren't right.
The description I was replying to had you hovering over little thingies for tooltips. The whole time you're writing code little popups and widgets are flying all over the place. That is distracting. Give me an environment that edits text please.
I'm with you on the crap flying around on every other keypress though. Feels like I'm programming with an extreme case of ADD.
Try Visual Studio for a month. At first you'll be like "get out of my way stupid intellisense popup" and then you'll be like "holy crap that just saved me 60 seconds... for the 60th time today." And then you go home early and use that free time to have sex with your wife.
Point being, it'll change your life for the better.
Trying it again now would be pretty far out of my way just to reaffirm what I already know, since of course I've long since left Windows entirely.
As you said, since you don't use windows, there's no point in you using it. But let me just say that it certainly sucked at one point, but it is now one of Microsoft's best products, IMO. They've definitely done a LOT of work to improve it.
How I long for the day of starting your project with only a blank document.
Each time I dive into another language, I feel handcuffed because I don't have the features and options that I get from Visual Studio. Once the "new language smell" has worn off, I find myself wishing for faster ways to develop sections of code. I miss instant code compilation and validation. The ability to hop around sections of code, immediately find all references, or catch compile errors at a glance are all things I take for granted until they aren't there. And don't even get me started on ReSharper. Those guys at JetBrains are glorified drug dealers and I am one very hooked addict.
All that said, it makes it very difficult for other languages to gain traction with me. At times, the software adventurer in me gets frustrated about this, but the pragmatic side of my personality (the one that likes food and a house) prevents me from giving up all those benefits.
The only thing I hate about C# is the 'magic' they keep trying introducing to the frameworks. ASP.Net was bloody awful but if you haven't checked out MVC 4, this is truly WTF were you thinking MS:
http://www.asp.net/web-api/overview/getting-started-with-asp...
GetAllProducts magically maps to api/products/
GetProductById magically maps to api/products/{id].
Fucking retards, just give me the tools, not the magic. It's so focused on incompetent idiots. It's even worse than the stupid and almost but not quite utterly useless user membership crap they infect your code and database with. That's what's pushing me away from C# more than anything else, the random magic that will suddenly kill your application.
I don't use membership so it doesn't infect my db.
(I do agree with you though - just because other frameworks have magic bits doesn't mean I like it in MVC. I would also prefer it not be there. I just don't think you can really pick on MS in this case.)
See ASP.NET MVC Routing as a example (kinda related to the above).
ASP.NET MVC is way too much of a RoR clone than is good for them. C# programmers aren't used to magic: they're used to compilers telling them about typos. Convention over configuration is nice, but it's essentially the concept of dynamic typing translated to frameworks. It fits badly in a statically typed language.
I'd have much preferred ASP.NET MVC to have less magic and, for instance, decent, controllable, IDE-supported and compiler-guarded routing.
Example: in an action method, parameter names are mapped to URL parameters. This is horrible, I should be able to change the parameter name in any method without calling code being affected. Or, when this is not the case (e.g. when C# 4's named arguments feature is used in calling code), I want a compiler error saying that calling code can't find the parameter anymore.
In ASP.NET MVC, I get neither of those things. I might have as well gone Ruby all the way, then.
In short, it's brittle.
Compiled languages have pros and cons, but if you're compiling anyway, please use all the pros to the max. APS.NET MVC doesn't, and that's a shame.
It's still a nice enough framework, but it screams "missed opportunity", much like all those Java libraries that were ported over to C# back when .NET was new.
That being said there is definitely a deficiency in strong typing in ASP.NET MVC as-is. That's why I use T4MVC (http://mvccontrib.codeplex.com/wikipage?title=T4MVC_doc&...). I'm not too sure how the MVC team have done things much differently, though, without overcomplicating the framework... you'll note the T4MVC approach is based on code generation that inspects your source tree.
I think code generation from inspecting source trees really is the future for compiled languages.
I used to think that the only reason to generate code (instead of using reflection or interpreting some DSL) was speed. I missed how code generation gives you excellent additional features, such as more compile-time safety and, most importantly, excellent IDE support. Once my code is generated, I can talk to it from other code like it was a hand-written library including all the IDE goodness (API discovery through autocompletion, etc) that it comes with.
I really hope they'll keep making T4 even more awesome than it already is. Combined with Roslyn, I think we'll get some pretty cool tools ahead that we can't even fathom now.
1. ASP.NET MVC implements customizable routing, like pretty much every other modern web MVC framework these days. The routing library can actually be used in old school ASP.NET Web Forms applications or your own raw ASP.NET application, if you like; it is not ASP.NET MVC specific.
2. The default route in the code generated as part of the "ASP.NET MVC Web Application" template project in Visual Studio maps routes as follows: /{controller}/{action method}/{id parameter}. There's nothing stopping you from (a) changing this in the generated source code (Global.asax.cs) or (b) generating an EMPTY default web application without the code at all and zero routes pre-defined.
but that is not hard rule as, for instance, haskell is potentially-very-IDE-aidable AND less verbose.
now only the haskell IDEs need to mature :) but this is a mater of time.
ConnectToDatabase()
CheckUserName()
CountPosts()...But even after splitting it into three functions you would still save 60% of your keystrokes by using auto completion ;)
Con()ENTERChec()ENTERCou()ENTERWhere C# and .NET really shines is in its native integration and low level facilities. How many other tools in the world let you debug a mixed application containing both native and managed code, all in the same IDE and in the same session, with the ability to set breakpoints in either area, view values, do memory watch points, and so on?
It also feels so incredibly easy to call native code in C#. There's even a whole web site dedicated to making it easier, pinvoke.net!
Lastly, C# itself contains several performance-sensitive features that have no JVM equivalent, including value types, unsigned integrals, and unsafe code with raw pointers. The .NET platform even has an implementation of tail recursion , now, though the C# compile will not generate IL that uses it, which makes it inaccessible for most people.
When it comes to language design, C# is a little sloppy but it more than gets the job done. In terms of tools and low-level facilities for building a real-world application, C# on the Windows .NET platform feels absolutely world-class.
For my favorite language, I of course, voted for Scala!
That said, the Mono experience on Linux is inferior to that on Windows. MonoDevelop is nowhere near Visual Studio, so that I just develop on Windows and deploy on Linux. Unfortunately, that doesn't help the fact that both the soft and hard debuggers for Linux are nowhere near Microsoft's debuggers. It also doesn't help the fact that the runtime itself is less stable (i.e., more prone to crash) and there are APIs that only work well on Windows. I would also imagine that the Microsoft runtime exhibits much better overall performance.
My understanding is that Mono mainly excels at MonoTouch, and that is where Xamarin is making most of its money, but I am not knowledgeable in that area.
Just a historical note: The Shared Source Common Language Infrastructure [1] aka "Rotor" is an alternative version of the .net 2.0 platform developed by Microsoft for research/education use. It can be compiled for FreeBSD and Mac OS X 10. Its rather out of date, but maybe shows that MS did make some kind of effort to make it cross-platform.
[1] http://en.wikipedia.org/wiki/Shared_Source_Common_Language_I...
I'm glad to see someone still uses it:)
C# is my new favourite language, and MonoDevelop is a pretty decent IDE for what it is :)
- The debugger is flaky. Sometimes it will miss a breakpoint completely. Sometimes trying to inspect local variables will crash MonoDevelop. Sometimes it will refuse to continue no matter how many times you tell it to.
- If your problem starts in Unity's native code, forget about trying to debug it. The messages are cryptic and the debugger is useless. This happens for some things you can diagnose (like running out of memory, either on the machine or the card)--although good luck figuring out what your memory hog was--and for other things that leave you completely stumped (shotgun debugging becomes your only recourse).
- Don't even attempt to use text search over multiple files (other searches, like reference searches, work fine). MonoDevelop will get stuck in an unproductive loop that never displays any results and never completes.
- Forget about profiling. Unity technically has a profiler, but it's per-frame, not cumulative. It also omits a lot of detail, especially about memory usage.
- There are also a number of minor issues, too, but they aren't deal breakers so much as annoyances.
That having been said, our particular project is rather good about pushing Unity to (and beyond) its limits, and you may never encounter any of these limitations. Still, it's worth knowing that they exist.
Footnote: These comments may be limited to the version of MonoDevelop that ships with Unity 3.3 (there are non-technical reasons why it's not worth our time to go through the effort to upgrade).
I hear you though - debugging Unity projects is a real toolchain weakness. I'm lucky if I can even get the debugger to connect.
Text search works fine for me though! I've never had a problem with it.
My worst problem with it actually is just stability, but I've never lost work with it and it restarts pretty quickly.
What are you working on, out of interest? (If you're allowed to say!) :)
> Most of those issues are with Unity not MonoDevelop, aren't they?
> Text search works fine for me though! I've never had a problem with it.
> My worst problem with it actually is just stability, but I've never
> lost work with it and it restarts pretty quickly.
> What are you working on, out of interest? (If you're allowed to say!) :)
Moreover, for maximum performance, mono provides facilities for users to embed native code into the runtime, much faster than Pinvoke.
From what I gather, HN isn't so much about being part of an "in-crowd" where you "just know" the way things are. You need to be willing to explain your arguments, otherwise you're just a snob.
I will be working on a Unity3D project and the team wants me to use C# with VS. As a Mac user and Open Source fan, I didn't jump at the idea. Glad to hear, that a lot of people think C# is a good choice. I'm excited to learn it!
Any suggestions for a good book or website? I've been programming in C and C++ quite a bit, but its been a few years. I've only been doing functional programming since then and would probably need a refresher on object oriented programming.
Can someone comment on the best development environment for Unity/C# when using a 2011 Mac Air with 4GB Ram? Should I install bootcamp, use Parallels Desktop or Unity+Mono under Mac OS?
For C# dev, it depends how hardcore you're going to be getting. Ultimately, you normally going to be scripting, not programming. getting familiar with the Unity3D API is of more use than learning high level features of C#. For instance, while C# is object oriented, >90% of the things you write will inherit from MonoBehaviour, and most of the rest are just fancy structs.
And I code on an iMac -- I use Unity natively, and the version of MonoDevelop it ships with. It works nicely!
There is no substitute for lambdas :)
Note that the Guava lib specifically points out how ugly this is.
I prefer Clojure.
Because, no "anonymous inner classes" are no lambdas. They are, well, classes kludgily used to mimic a lambda proper.
Since the former have a proper name (closures) and the latter doesn't, I'd be inclined to call only the operator a 'lambda'. But since you can at least 'approximate' closures in Java (with anonymous inner classes), I think it's fair to say that they are "very verbose and awkward lambdas", to some definition of lambda.
Sort of. It just so happens that the tail call optimization does get used on x64 platforms because of an implementation detail of the 64-bit JIT.
Source: http://blogs.msdn.com/b/davbr/archive/2007/06/20/tail-call-j...
I'm with you that C# is really nice to use, but interfacing with native code is a nightmare. The reason why a whole bunch of websites exist on pinvoke is because of its poor documentation and incoherent behavior.
As far as low level goes, I'm happy with C++ (if I were an embedded engineer I would say C but it is very nice to be allowed to use the C++ niceties). I think that everyone needs to have a language that can generate native code. On higher levels, python is fine for me. I simply do not have the use for an intermediate language like C# or Java, however nice they are.
+100000. We can thank the Webkit Tools team (including folks from both Apple and Google) for making the web platform environment as pleasant as it is. Kudos!
1. http://www.opera.com/dragonfly/features/ / https://bitbucket.org/scope/dragonfly-stp-1
webkit originally comes from the KDE project and was known as KHTML (with its KJS companion).. they basically showed the world that a decent HTML renderer can be written in nice-API-C++-code (Qt-style-nice-API) and with limited resources.
how long did Mozilla take to make Netscapes ancient codebase usable? it took forever!
and chrome+safari+android+iOS >= 40% of the browser market. wow.
anyway, lets also thank the KDE project that booted it. :)
Actually, I think this is a bad example because oop is inadequate in this particular case. Converting something to something else perfectly fit the functional paradigm (take an argument, returns something, don't store anything). Why do you need a Convert object? How would you explain this to someone not familiar with C#.
I think Console.WriteLine("hello"); is a better example.
If you're implying that it has to do with the lack of visible scores, I'd point out that I think that the comments are still ordered by score, even if they aren't necessarily displayed.
If it's just because of the sheer number of comments attached to the C# specific parent, I can't remember a time when a really popular comment didn't take up a larger share of space as more comments logically take up more space.
I mean, there was the pre-pagination era, where you could just keep scrolling down, but that was also the era of HN crashing all too frequently.
I suppose it IS a fair point though, especially considering that C# is (by my quick once over) only the fourth most popular language, and easily represents the most popular discussion on the topic.
Also, looking through the additional pages, it seems as though there aren't many other comments that even have children, much less anywhere close to the same discussion space.
I use tmux (with tmuxinator), with windows for my editor, shell, debugger, source control, logs. I'm able to, effortlessly, change any part of it.
Effectively you (like me) have probably put together your own set of tools that perform the functions of a IDE.
It will be interesting to see what happens with C# if Microsoft succeeds with Windows 8 on the desktop, tablet, and phone.
Is this normal or is it just me? Don't you come to like, or love, a new language? Every time I do something different I realize how good things could be. But this is just a case of "the grass is greener on the other side" I guess.
I ended up voting for Perl as it feels the most fun language. But ask me again in a month and you might get a different answer.
Book recommendation: Thinking Fast and Slow by Dan Kahneman. Great overview of how those factors affect decision making.
But this "Java" thing keeps paying the bills for most of the last decade. I guess it doesn't do everything wrong. (as much as I'd like closures & function pointers, tuples or even working destructors sometimes, I get by with Java)
I believe this happens because language design involves a lot of trade-offs, so every language incorporates these trade-offs.
When one is comfortable in many kinds of languages, one is in a special position to see the trade-offs in the design of the language one is currently programming it.
The way I see it is slightly different then the way you describe. Say I'm programming in Prolog, for instance. In the beginning, I'll be like "Wow, such expressiveness". But inevitably I'll do something that is outside the scope of Prolog and it will be as slow as hell. That's when I think to myself: "if I could just fix this little part... I miss C". So when I'm back programming in C I'll think "now my code is fast", but then inevitably: "if I could just find a way to do this without so much repetition".
In the end, it comes down as a "right tool for the job" thing. One possible ideal would be do the things Prolog is good at in Prolog, the things C is good at in C (and also throw in some Python, Erlang, Lisp, etc). Except most of the time this is infeasible. Working with FFIs suck. Sometimes there are no FFIs, sometimes there are many incompatible ones, and the dream of calling any language from any language is just further and further apart. And don't get me started on the pain that it is to have multiple runtimes with slightly different semantics...
Even if it were possible, a developer would have to learn all these little languages enough to be working on them comfortably, and we all know this is not going to happen. So hardly anybody does this, as hiring someone for a polyglot project is a complete nightmare.
I know shell isn't going to with this popularity contest, but a return to it is what's badly needed in CS today. Instead of attempting to recreate the shell in C# or Java's supplied libraries and subsequently becoming frustrated when interaction with the "outside world" is clumsily accomplished through an FFI pinhole, just use the shell as it was intended: as a lingua franca between utilities.
Write what requires prolog in prolog, what requires c in c, what requires awk in awk, etc. Use flat file databases such as starbase or /rdb and avoid data prisons such as MSSQL, Oracle, MySQL, etc. Make all of these utilities return sane return values and spit out JSON formatted output. Finally, tie it all together with shell. If you need a UI, code it as a thin layer in TCL/TK, python/pytk, ansi c/gtk, or, consider pdcurses, etc. Profile your program and find any weak links in the chain. Recode in a lower level language only when needed.
Programming doesn't have to be hard. As in speech, the more one says, the less one means.
The Web, of course, has been recognized as the cause of the recent proliferation of and resurgence of programming languages. As long as you speak HTTP, it doesn't matter that you're a dog.
And I think it is no coincidence that the creator of Unix is one of the designers of Go, a language that shares Unix's conceptual and implementation simplicity, makes very conscious tradeoffs and where channels work somewhat akin to pipes.
Of course interfacing with the rest of the world has become much harder thanks to XML, SOAP, XMPP and every other such monster, but as somebody else pointed out, the modern equivalent seems to be REST+JSON, I would have preferred something like 9P, but oh well, one has to pick their battles.
As for Perl, I used to hate Perl for its many arcane ways of doing the same thing, but I then forced myself to do some Perl scripts at a job and it's not too bad. It got the jobs done. Since then I've used Perl for many quick scripts.
No, it is not there yet. The hope it that it one day will be. Because that would be amazing. It is already about as easy to write as Java, and usually beats it in performance.
Hypothetical example. Let's say that 1/4 of HN likes C, then Lisp, then Python, then Java. 1/4 of HN likes Python, then Lisp, then C, then Java. 1/5 likes Lisp, then C, then Python, then Java. And 3/10 like Java, then Lisp, then Python, then C.
So we have:
1. Java has the highest number of votes, even though 7/10 of HN thinks it's the worst language. Java wins!
2. Lisp has the fewest number of votes, even though it's the only language to appear in the top two preferences of 100% of the voters. Lisp loses!
In other words, the results from your voting scheme suggested the opposite of what people really liked (and disliked). This is a known, and very common, pathology of single-vote-plurality and becomes more and more of a problem the more candidates enter the race (and you have a gazillion of them).
Since you can't have people easily express their rank ordered preferences on HN (eliminating Condorcet, IRV, and the like), the next best thing would be to do approval voting. To do approval voting, you'd change the wording in your posting to:
"What languages do you like? Vote for as many as you want."
Then the winner is then the language with the most votes.
Put another way, there are a fair number of HN articles about PHP but I don't think that's because it's an inherently great language.
Clojure 28.8
Python 26.5
Haskell 19.7
C 17.3
Lua 16.4
Lisp 11.5
Erlang 9.9
Ruby 8.4
Scheme 8.1
C# 7.9
OCaml 7.3
Smalltalk 7.1
Scala 6.4
D 4.4
CoffeeScript 3.6
JavaScript 3.5
Forth 3.2
Groovy 2.9
Assembly 2.5
Ada 1.7
Objective C 1.6
Perl 1.6
SQL 1.4
Pascal 1.3
Rexx 1.3
Delphi 1.2
C++ 1.0
Tcl 0.9
Fortran 0.7
PHP 0.7
Shell 0.7
Java 0.6
Actionscript 0.6
ColdFusion 0.4
Cobol 0.1
Visual Basic 0.1I especially like the lack of a type hierarchy. I have come to think that type hierarchical structures are somewhat brittle - you create these initially correct representations, however when something changes or isn't quite right suddenly you either have to rewrite your hierarchy which is potentially a lot of work, or hack it up whereby it ends up not only incorrect but also misleading.
In go, you get implicit, dynamic interfaces whereby you define an interface and get duck typing against it without having to explicitly indicate that types implement it. The capabilities of a type determine its abstraction, nothing more.
I use C# a lot, and I love it. But it's tied into MS's heavy stack for web stuff (ASP.NET, etc.) so recently I've switched to using node.js and CoffeeScript in my projects. It's fantastic. So right now my favourite language is JavaScript/CoffeeScript, but just because of the things I can do with it.
I am hard pressed to find a better reason to like a language or stack.
But I can't do anywhere near as much with it.
I'm not especially fond of the Haxe language, but it's Good Enough that I'm happy using it day to day.
However, its ability to export to so many different targets (C++, Javascript [+ Node.js], Java in beta I believe, Flash SWF, AS3, Tamarin, PHP etc) is a real killer feature.
Would that count towards this poll or not?
Wouldn't be awkward to use Haxe for a project that employed language specific APIs? It seems like the sweet spot would be using it to write basic libraries that had no external dependencies.
Platform specific APIs are awkward, which is why it's mainly used for writing games. NekoNME abstracts most of that away. I'm not so sure how easily it does node.js.
But the standard runtime for Haxe has been ported to the other languages in a fairly bulletproof way.
Any other reason why someone might want to use it?
For what it's worth, ASP.NET MVC is much, much less heavy than the original ASP.NET (if that's what you're referring to). This is especially the case if you use the Razor syntax for your views.
This is something that always bothered me about Microsoft-related stuff. Right now I'm using Python and Django for web development. I'm also using Ruby on Rails for a side project. Having access to the source code is vital for me as I've become accustomed to reading a lot of source code. And reading source-code for lack of better documentation is sweet, but then I went further and for instance I also copy/pasted a lot of snippets straight from Django's source code, or worked-around bugs by patching components.
That's why I consider open-source to be superior, regardless of all the polish that Microsoft is able to apply to their products. I'm a software developer, not your average user. Just as a sports-car racer would find unacceptable the lack of access to the internals of her own car, I find unacceptable the lack of source-code that I can read, modify and distribute.
For pure debugging purposes, have you tried using a decompiler? For reasonably well-written (and not obfuscated, naturally) code, the decompiler output is remarkably clear.
And thats if you even use that... I use 2 open source libraries to build web apps - Nancy & Simple.Data - and they are both f'in amazing. This is about as "light" as you can be. I have a prezi presentation on my blog about using these libraries to build web apps for a few talks I gave at code conf's. (thinkdevcode.com)
What I am surprised at however is that C# and Java (37 and 35) are doing as well in this poll as they are. It seems that Java in particular is disliked here for it's heavy reliance on classes, classes everywhere, while C# is more approved of, but still disliked. Partially for the same reasons, but also for how Windows-centric it effectively is.
I guess it shows that HN isn't as seperate from a typical subset from programmers as it appears from just reading articles that are upvoted, and reading comments.
Personally, my favourite is Python, but between college and Android development, I've mostly been writing Java for the last few months. While I find that Android makes it less painful than applications using other big Java APIs (Swing for example), I'd still rather be writing Python.
I also wonder how different the results of this poll would be from a similar poll asking "What language do you write in a daily basis?". I'd imagine Haskell and Coffeescript as the biggest losers in such a comparison, while I'd imagine that PHP would have the biggest gain.
Also obligatory #golang so people can search for it on the page! (Had to sift through every "x hours a<go> to find this thread.)
If you asked me a year ago, I'dve said python. But lately, I've been using Clojure for personal projects, and it's making python seem just... boring. (I get the same feeling when I write in Ruby too)
The "one right way" paradigm is a great one, and the language is solid. The built-ins are top-notch, and while not exactly a functional language, it's certainly expressive enough. In my mind, it's probably the ideal general-purpose language. But lately, I feel like I use it for everything because it's "good enough" for everything -- without being "great" at anything.
Point? I don't think I had one, sorry. I just thought I'd share that notion to see if it resonated.
I'm mostly programming in Python and JavaScript today, and I want to learn Clojure, but I keep seeing these very strange talks. I don't know how to articulate it, really. My best metaphor is, it feels a little like I wanted to go out and learn about Catholicism and they said, "oh, that's easy, we'll just have you sit in on a bunch of confessions and you'll figure it out in no time." People explain why they made certain language decisions and I (as yet) lack any of the background needed to know what the hell they're going on about.
I think another thing that gave me a boost was when, for whatever reason, I decided that I should avoid for loops when writing day-to-day python. I started using list comprehensions, and then map, filter and reduce, and functools.partial, whenever possible. I had tried to approach lisps before, but I found it easier after those became habitual.
[1] Ring: https://github.com/mmcgrana/ring
[2] ClojureDocs: http://clojuredocs.org
[3] Pump: http://adeel.github.com/pump
overtone comes with a stock emacs config that will get you livecoding in no time.
after that, Joy of Clojure by Fogus. (edit: fwiw i have had no trouble with this book even as my first lisp, but i've been coding in a functional style for about 6 months before clojure)
Clojure force you to think and program in functional manner, where in Python you can skip FP. Thus learning Clojure IMHO will improve how you program in general. I am learning Clojure now for this purpose and I might not use it for real work.
http://books.google.com/books?id=a47neDIBaSkC&printsec=f...
It starts assuming virtually no background in the faith and it really gets you into the nuts and bolts quickly.
This is probably because describing the virtues of Python (clean & simple syntax, one right way to do everything, easy-to-use yet comprehensive standard library) just feels like beating a dead horse. Almost everybody in this community has heard of Python. The circle-jerk factor on HN is still somewhat low when it comes to this topic.
I currently use Python personally and professionally, and I love having it as my go-to language. However, I'll be happy to add some more languages to my repertoire in the future.
It is my favorite language simply because the pseudocode I write on whiteboards is basically Python. Strangely, it has been since well before I really started using it regularly.
I don't believe (but correct me if I'm wrong) that Ruby has ever gained much traction outside of the software development world. Perhaps we're just seeing some natural consolidation.
But generally, I think it's good to pick the right language for the right domain. I keep trying to find an excuse to learn Erlang ;>
> ...go towards C (or occasionally even fortran) when I
> need something faster
I'm not trying to talk down PyPy here, but for this domain of application, it's not appropriate at the moment.
It was one of the first languages I used which really introduced me to a completely different way of problem solving and thinking about the structure of a program. I know that language was probably Lisp/Scheme for a lot of people, but for me it was Smalltalk. Implementing control structures without language keywords!? Operators implemented using the same message passing techniques as any other method call!? Querying any instance for its implementation and documentation at runtime!?
(As a pre-emptive strike, Mono does not make .NET any more "open". If Mono was maintained and supported by the same people that design the language/APIs I might change my tune.)
There is of course a particular implementation of that language which is proprietary, closed source, and tied to a particular platform. However, this is not a particularly unique feature of the language. The same is also true of ECMA-262, ISO-1539, ISO-9899, ISO-10279, and many others.
For its part, Mono is supported by the same people that design the Mono branch of the language/APIs. This is a quite robust fork of the platform, which includes a great many useful APIs which are specific to that version, and forms the foundation of popular tools such as the Unity game development framework.
If Microsoft controlled both major implementations of C# and .Net, you'd consider that more open? Maybe you should think about that a little bit more.
Of course, I do research on Manticore (parallel dialect of Standard ML) and am one of the primary developers left on the SML/NJ implementation. So I'm a bit biased.
But trying to be objective, the module system is absolutely amazing. It's a simple / small set of syntax with a formalized semantics that is powerful enough to do almost everything you want to do with generics, classes, macros, and other module systems.
I mostly use Haskell myself. I find myself missing the laziness and purity when I use Standard ML, but I think the biggest obstacle for me is the shortage of libraries. I'm happy to use a language without a community, but compared to Haskell it feels a bit like a ghost town. Such a shame, it really is fantastic and would have been the perfect tool for building huge systems on.
Yes, the overloading issue requires changes to both the parsing rules and some fairly tricky formal semantics changes as well. I've talked with Dave MacQueen about it in the past, and it didn't sound like something he was terribly averse to, just that it would take a long time to really get _right_. And then it places a burden on the SML implementations, though at this point that's really SML/NJ, MLton, and possibly Poly/ML (though I don't know that team very well yet).
Unfortunately, the SML implementor community largely either moved on to other research projects after the implementation-y papers had been mined or left to work in finance (interestingly, it seems to be about 50/50, with the exception of a Googler or two). We don't really have anybody in research labs to do the kind of amazing full-time implementation, support, evangelism, and publication work that the Simons do so fabulously for Haskell!
That said, as a researcher, having many more SML users would require us (particularly Manticore) to Get Real in ways that are not on the path to publication. And considering I'm already only going to have 7-ish publications when I graduate, I see a probable future locked behind the doors of Big Finance for myself as well...
But for most it's not their primary language; those roles are usually still filled by C on the server and some GUI-friendly language for the trader apps. It's mainly used less latency-sensitive work that is more financial modeling in nature.
Sorry for being vague with names; other than Jane Street and Standard Chartered, most of them will only talk about it confidentiality. Many take secrecy to the point of lunacy.
I gotta admit I miss Occam but it is over 20 years since I did any programming in it. I am currently researching agent based languages as I still have some Telescript documentation and have always been fascinated by the concept.
Objective-C isn't a particularly pretty language, in my opinion - but when XCode's powerful code completion, decent visual debugger, and awesome static analysis come into play, it's a lot more attractive.
Plus, for me, programming is about the goal, with the journey an oft-pleasant and very engrossing side effect. Objective-C hits the sweet spot where the language and toolchain gets out of my way and lets me build beautiful, functional software that people actually use.
I am not a bearded hacker. I'm only 26, but it seems that everyone in my age group has moved onto fashionable web programming tool chains, Ruby, etc. Personally, that's just as well; leaves me with less competition. :-)
(Perl is still my "favourite" of all the languages I get paid to write…)
I code mostly in C# for employment reasons, but I do personal code in F# or Python, depending on what kind of tools I need access to.
- Ruby for an imperative scripting language
- Go for an imperative systems language (previously C)
- Clojure as a functional language
Python, simple enough to explain why. I get to quickly make and test a program with a language that is well documented, comes with a tutorial that in my opinion was just as good at getting me into programming with Python as any other books I've found out there, and the growing libraries for AI based fields is very nice. Lately (doing the NLP class, and was using SimpleCV/OpenCV for another project.) I've grown to love it even more then before.
As for why Assembly was my second runner up? One very simple, but hopefully thought provoking reason. Assembly Language was the absolute most simple yet complicated programming language I had ever dealt with, it taught me more about how and why computers do the things they do then anything else I learned about computers. (since I keep people's computers going as a living, it was extraordinarily helpful in making me a pro at fixing them.)
In Perl I can be witty and find my personal style. Sadly enough, my code poetry might not be somebody else's. Reading other people's Perl code can be hard.
On the other end of the spectrum, Python feels aesthetically dull to me sometimes. But it's a great language to program in with larger groups of people, even when they have different skill levels and coding styles.
In the end, these languages are all just tools; you can do a hammer's job with a screwdriver, but really all tools have their purpose in the right context.
(Go's missing, though.)
I also love OCaml (and miss it's static inferred typing and pattern matching everywhere else), but it's ecosystem has never fit with what I'm working on outside of coursework in it.
http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html
This article gives a good insight what about LISP is so awesome:
http://www.defmacro.org/ramblings/lisp.html
I also vote for Ada because this is the best language I know to write maximum quality software. I would love to make money for living by coding Ada for Embedded Systems.
Quick tip to get the appropriate tone right. Don't post anything that sounds like a typical Reddit comment.
(Don't worry, I have a ton of karma to burn here)
When it comes to getting stuff done, Javascript is an interesting language, and there are some things about it I like a lot, but there are many things in it where a) there is syntax for things that make no sense (like the ~ operator), b) the syntax for something common and important is horribly clunky (like function, or assigning to a prototype), c) the syntax having odd rules that almost seem like little traps (like the way that () will call the previous line as a function, or how you need a trailing comma on everything in an object literal except for the last thing). All that being said, I love what I can do with it. And I really find that CSS/JS/Semantic HTML has some of the nicest seperation of concerns of any UI programming toolkit I have looked at. So when it comes to what I can build (and get paid to build), I would say my favorite language is javascript.
I use C the most because it is the most appropriate tool for the job at hand for most of the jobs I do. I appreciate the simplicity and elegance of Scheme, and wish I could use it more. I envy Haskell's type system.
None are my favourite. After all, all programming languages suck.
However, Ocaml is not the end of it. I know of Haskell, and I sometimes resent Ocaml's value restriction, or lack of laziness. I know of Lisp, and I sometimes resent the complexity of Camlp4.
However, Haskell and Lisp are not the end of it. See, http://vpri.org/html/work/ifnct.htm and http://www.vpri.org/pdf/tr2011004_steps11.pdf showed that with the right tools, a few hundreds lines of code is sufficient to make a TCP stack, or a Cairo-like graphic system, or even a whole programming language stack that's more powerful than Lisp itself. When I see that, I know that I think Lisp, Haskell, Forth… are already obsolete. The market just doesn't know it yet.
However, COLAS and OMeta and Maru are probably not the end of it…
Of those languages, C# feels the most feature rich and easy to read, while I find working with the Cocoa framework and Objective-C particularly enjoyable. The others I work with but find no particular enjoyment from.
That's certainly a correct answer, but it's correct because it's almost tautological. 'The language that I like the most is the one that's best [for what I want to do]'. The issue is that, in this question, 'favorite' is a bit vague, and the task isn't specified. (This is why I have a problem choosing 'favorites'.)
Despite that, in this situation, I interpret it to mean 'What [general-purpose] language has the best design?' Theoretically, a perfectly-designed language would be designed in such a way that it has an absolute advantage over all other languages for every type of task.
Given that definition, it follows naturally that I would choose Lisp - it's actually not my strongest language, but even a novice Lisper can see that Lisp is both as minimal as possible and yet as powerful as possible . Since it's a shapeshifter of sorts, it can adapt itself perfectly to any setting.
The drawbacks with Lisp (in my view) have nothing to do with the design of the language itself, but rather the environment. The libraries of languages like Perl and Python are much larger, by sheer fact that the community is larger. Lisp is cross-platform, but the installation (quicklisp aside) is still messier than Ruby's gem-based packaging or Python's eggs. And lastly, because most people don't learn functional programming as their first step, it's got a learning curve.
But none of those are problems with the language itself - at least not the design of the language. (I'm assuming here that we're dealing with high-level languages - it wouldn't really make sense to compare x86 assembly to Python - if you're writing assembly, you probably have a very good reason, and Python isn't even on the table).
So in the end, your answer to this all determines on how you interpret the question, so it's fun to see what the results are... just don't try and compare them directly - I think anybody who interpreted the question the way I did would probably choose Lisp, but it's clear from the comments that many other people interpret this a different way.
(Thankfully HN is good at avoiding flamewars, but I'm sure everyone here has seen enough useless 'debate' of this same topic on other forums to understand why I mention it!)
Debugging is not as slick as in Visual Studio-land but... that's what test coverage is for! (and it's super easy to do...)
Here, I wrote a class today which subclassed Delegator (https://gist.github.com/2305169) that will let you return a value from a function that looks like a typical single scalar value but actually has "hidden" attributes riding along with it. Smoke and mirrors :) This is the first time I used this class or the Delegate pattern for that matter. (I came at programming from a Psych major.)
Notice the test inline with the class definition itself at the bottom that is only run when the file itself is run (not when it's merely included by another file). A simple Command-B (for Build) in Sublime Text 2 and I get the tests passing in a split second and know I didn't break anything.
A few years ago when working for a bank in Germany I had to learn Rexx but only for some extremely unsophisticated stuff - so I am asking: What are you doing with Rexx and what makes it your favorite programming language?
Emacs and Vim? Twenty years later and these are still the state of the art? Even when our computers are at least 1000 times more performant? I guess there are IDE's out there trying to do better, but in the end I'm still typing text into a computer, occasionally getting autocompletes that is exactly what I want, but usually its not.
Do I like programming? Yes I do, I like programming more than I hate the tools I have to use.
I think I really want an immutable-data language that uses rubyish message-passing style.
Simple and conceptually-consistent languages that my simple mind can fully understand.
Anyway, put me down for "Groovy" at the moment, although it could potentially be knocked off that perch at some point. I have some other languages I'm interested in exploring but haven't gotten deeply into yet.
I have to use it during the day, but use Ruby on my side-project. Tcl and it's lists (and lists-of-lists) is wicked painful - especially compared to my Ruby experience at this point.
1. A runtime environment 2. A software ecosystem 3. A language.
:)
So you can use 1. and 2. without having to write a line of Java if you don´t like it. There´s plenty of languages that run on top of the Java virtual machine: JRuby, xRuby, Jython, NetRexx...
Even Lisp and Cobol if you want.
http://en.wikipedia.org/wiki/List_of_JVM_languages
There´s a yearly summit about new languages ported to the JVM... http://openjdk.java.net/projects/mlvm/jvmlangsummit/
Does that sound about right to those of you with more experience?
It's no accident that services like Dropbox[1] or YouTube[2], both arguably very complex systems, are relying on Python as their language of choice.
[1] http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-how...
I hate PHP but it is easy to write a quick backend in which can be deployed everywhere. I hate Javascript, but it is hard to beat it in the browser.
I summary I don't have a favorite language, they all kinda suck and kinda don't. It all depends on what I need to use them for.
1) all the libraries are it takes advantage of are written in Java and this doesn't fit the closure style of coding at all.
2) the available tools just suck. Sorry, but without autocompletion the time it takes to write something balloons way, way too high.
I guess 2 would have been less of an issue 20 years ago -- back then most of the IDEs that we use today did exist -- but it is not 20 years ago. It is now.
I am not particularly impressed with most things which aren't Lisp based or which aren't at least functional. In particular, I am not impressed by Python. Admittedly, I am biased towards functional languages like Lisp because I am a mathematician.
With less theory to learn compared to other languages, the power of C lies in the implementation only. Just few simple ayntaxes combined with terrific logic can make some really powerful applications.
Also, maybe little bit nostalgic here, but it feels good to return to C every now and then just to make some highly logical program and challenge the logical side of my brain.
Ruby is consistent and cool, but I can do everything I want with Python and I can make it FAST as hell.
Over the past week I've been moving some things into Cython and it has literally sped 200 times faster than Python which is 10 times faster than Ruby, and with a lot less memory overhead. Speed _does_ matter when the two languages are nearly the same in terms of development speed. Furthermore Python has more libraries and less wtf moments when looking at peoples code.
Haskell because it makes me do what I ought to do.
Ruby for when I'm doing configuration management or occasional webdev.
Fortran for when I'm doing serious computation, C for when I'm trying to do something fast that isn't number-crunching. (Though I'm trying to learn Go for that.)
And a smattering of other languages (Perl, shell, Java, etc) for interacting with tools that speak those better than anything else.
In general I find that Python is the easiest language for me to "think in", syntax-wise. It is almost pseudo-code in its simplicity, and I like that it has extremely powerful namespaces. It also seems to me that it's easier to write programs in Python which ignore object orientation in favor of a more functional style, than it is in Ruby. I'm slowly falling out of love with OOP, and Ruby loves its objects.
I also really like Python's libraries for numerical and scientific work. For whatever reason, Python took off in the scientific community, and it's got libraries like NumPy and SciPy which I haven't seen duplicated in Ruby. It's also easy to integrate with existing Fortran and C libraries... and if you've done much work with Fortran, you know that it might be blazing fast but it's not the most pleasant thing to work in. Much nicer to glue it together with Python. :-)
Where Ruby shines for me is in its libraries for server configuration and web development. I like Python's webdev libraries, but I still find it easier to work with Rails or Sinatra than with Django or Bottle. I also think that Chef is one of the best things ever for managing servers in a programmatic fashion, and for that you need Ruby.
Granted, they have been adding some very useful features to the language over the past couple years that I rely heavily on, but I'd never go so far as to call it my favorite.
After awhile, I think most people even begin to appreciate it's verbosity. You can make it read like english pretty well.
Of course, I'm sure I wouldn't like Objective-C without Cocoa or I wouldn't like writing it on Windows.
I've never been able to get round the whole whitespace thing in Python and Ruby. I really like brackets and they've always been the strongest thing to signal where code starts and ends.
I put up with the standard library, I'm not thrilled about there being so few decent cross-platform IDE's supporting Python, and module hell can drive me nuts, especially considering the fact that a minor version discrepancy means the module won't work (e.g., module built for 3.1 refusing to work on Python 3.2, although perhaps there's an incredibly simple solution to this which has evaded me thus far).
I use C# and Javascript at work, and enjoy both. (Not saying I enjoy .NET though, just the language.) I like the way C# is evolving towards functional programming and includes new paradigms while retaining the (ostensible) familiarity of Java and C.
Clojure is a great language and there is a great community around it. Here I am just a beginner, though, and it is not part of my everyday life. Hopefully it might change in the future.
f = open('langs.txt', 'r') content = f.readline() while content != "": line = content.strip() if line != "": temp = {} parts = line.split(" ") if "points" not in parts: temp['title'] = parts[0]
nextline = f.readline().strip()
parts = nextline.split(" ")
temp['score'] = parts[0]
langs.append( temp )
content = f.readline()
"""
[{'score': '6', 'title': 'Cobol'}, {'score': '6', 'title': 'Rexx'}, {'score': '7', 'title': 'Fortran'}, {'score': '8', 'title': 'Ada'}, {'score': '8', 'title': 'Pascal'}, {'score': '9', 'title': 'Groovy'}, {'score': '12', 'title': 'ColdFusion'}, {'score': '14', 'title': 'Delphi'}, {'score': '14', 'title': 'Tcl'}, {'score': '16', 'title': 'Shell'}, {'score': '18', 'title': 'Forth'}, {'score': '20', 'title': 'D'}, {'score': '23', 'title': 'Visual'}, {'score': '24', 'title': 'Smalltalk'}, {'score': '29', 'title': 'SQL'}, {'score': '30', 'title': 'Assembly'}, {'score': '31', 'title': 'OCaml'}, {'score': '32', 'title': 'Actionscript'}, {'score': '51', 'title': 'Lua'}, {'score': '57', 'title': 'Erlang'}, {'score': '74', 'title': 'Scheme'}, {'score': '92', 'title': 'Scala'}, {'score': '100', 'title': 'Other'}, {'score': '120', 'title': 'Perl'}, {'score': '123', 'title': 'Objective'}, {'score': '125', 'title': 'Lisp'}, {'score': '163', 'title': 'CoffeeScript'}, {'score': '187', 'title': 'Clojure'}, {'score': '192', 'title': 'C++'}, {'score': '194', 'title': 'Java'}, {'score': '205', 'title': 'Haskell'}, {'score': '235', 'title': 'PHP'}, {'score': '303', 'title': 'C#'}, {'score': '355', 'title': 'C'}, {'score': '515', 'title': 'JavaScript'}, {'score': '718', 'title': 'Ruby'}, {'score': '1133', 'title': 'Python'}] """
Warning: file_get_contents(http://open.dapper.net/RunDapp?dappName=HNChart&v=1&applyToUrl=https%3A%2F%2Fnews.ycombinator.com%2Fitem%3Fid%3D3746692) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 503 Service Temporarily Unavailable in /home/content/c/a/l/callindia/html/hnvote/hncharts/chart/index.php on line 6
Error fetching the Hacker News Poll.1. DOS batch scripting (1994)
2. C (1996)
3. Bash (1998)
4. Pascal (2000)
5. PHP (2001)
6. Ruby (2002)
7. Javascript (2004)
8. Python (2005)
9. Ruby (2009-present)
Now I'm in love with Ruby more than ever, I turned it down several times during my college years in favor of Python, but finding Ruby is like finding your true love. I was in loved with her more than ever. I have gone through Python, and back to Ruby and I am much happier as a programmer. :-)
Which should have been just: (print "Hello world")
Python 2591 22.17%
Ruby 1451 12.41%
JavaScript 1182 10.11%
C 817 6.99%
C# 678 5.80%
PHP 544 4.65%
Java 460 3.94%
Haskell 450 3.85%
C++ 449 3.84%
Clojure 388 3.32%1. Go 2. Python 3. Everything else
http://blog.codeeval.com/the-most-popular-programming-langua...
So, like, JS was my second language. Ruby and Clojure have as yet proven impenetrable for me to learn, but I'm working on that. I have shell scripted and done plenty of PHP, Python, Matlab, and Java, and I learned Scheme when using SICP but I feel like I never have anything available when I'm writing in it -- I hear Haskell is much better at this. I have seen some Smalltalk and it looked very pretty, some C and I was able to trace through it but I felt nervous as hell. That's the extent of my education.
My point is, out of this, the only stuff that I know well enough to choose my favorite is PHP, Python, Java, and JS. This poll cannot give a meaningful result for the question of "what languages are good?" without also asking everyone who responds: which languages have you written more than a hundred lines of code in? which have you read more than a hundred lines of code in? Then we could ask, "given those that have used X, how much has it been loved?" and get a measure of lovability.
Runner-ups:
Clojure, because it's different and elegant.
Javascript/java/c++ because sometimes it needs to work in browser/use some library/be fast.
Also Lisps could be merged into single entry since all shell languages are one.
The question is like asking a carpenter what their favorite tool is.
It'd be more enlightening to (somehow) ask what kinds of problems people apply each language to.
But giving an answer I'd like to vote for Go. :)
- Ruby, because it's easy and straight forward with lot's of nice features
- Python, because... I don't know. I just enjoy writing Python code :)
I like Perl the best and javascript+ruby the least.
Maybe I'm missing something about Perl?
You better follow the best practices for Perl and it is like the other scripting languages. Check the Modern Perl book.
My reason to prefer Perl is because it is fun and the culture is good. The business case for Perl is CPAN. E.g., check Moose and additions like http://search.cpan.org/~flora/MooseX-Declare-0.35/lib/MooseX...
+1 Groovy!
It's really fun to use; a bit like Python but with the benefit of static typing.
By the way, Ruby is pretty well scored also. I should try it eh. Is it for back-end programming or front-end, native apps? What's the point with it?(Really less code?)
And about Python? Why is it so awesome?
Because you already know it. Turn around and look at the pseudo-code on your whiteboard.
I highly prefer engineered coding than syntaxic coding. So there is no code in my white board, only -french- words. Code follow. And unlike mathematic and what most people think, concerning coding, details never stop you. Or really really really rarely. Bad design (=engineering) do and a lot.
OCaml wins on fundamentals. Scheme also rocks as a language. That said, there's something exciting about being able to leverage the latest OS technologies and solve the hardest real-world problems, which is an asset for the leading JVM awesomenesses: Scala and Clojure. Java sucks but there's a lot of awesome stuff available in that ecosystem (if you're discriminating and tell the FactoryFactory crowd to consider careers in investment banking).
I just got off a 3.5 month consulting gig and I'm really itching to buckle down on a hard Scala or Clojure project. I would probably vote for Scala because static typing is such a huge win on large systems where reading others' code is as important as writing new code. It actually makes reading others' code fun to have static typing, because you get automatic documentation of structure right away.
XSLT is a wonderful thing.
Epic poll failure!
Of the ones on the list, I'd say C# is my favorite language though I virtually never use it due to the practical and political problems that tie it to Microsoft.