Hacker Newsnew | comments | show | ask | jobs | submit | login

We're bringing CoreCLR to Linux/Mac (in the open) as we speak so hopefully you won't have to worry about ever being a second class citizen.

reply


We, another team not related to Locke1689, are bringing the CoreCLR to FreeBSD. 'Gotta prevent linuxims like #!/usr/bin/bash from infiltrating the codebase.

Discussion and project planning is happening here:

https://github.com/dotnet/coreclr/issues/455

If you want to help out make sure you stop by and say hi :-)

reply


What happens to Mono then, are you talking to them?

reply


The .NET team has always been on friendly terms with the Mono team. I'd imagine the Mono devs will either keep doing their thing or will merge into the mainline at some point. There's Java VMs that are even commercial, as in people pay for them. I'd imagine that there's certainly enough space for a couple competing CLR platforms.

reply


Merge - Xamarin are getting out of the language game and instead focusing purely on mobile. As much as possible the new MIT licensed .NET will replace pretty much all of Mono that isn't Mobile (iOS/Android/Mac) related.

https://twitter.com/migueldeicaza/status/581068613542649856

https://trello.com/b/vRPTMfdz/net-framework-integration-into...

reply


Check this out: https://twitter.com/migueldeicaza/status/581068613542649856

reply


mono + .net are merging, see the following Trello board to track the status https://trello.com/b/vRPTMfdz/net-framework-integration-into...

reply


Short story about exception filters: they're mostly there for crash dumps.

The background is that there is a piece of functionality in Windows previously called Watson, now called Windows Error Reporting. It's that dialog that pops up when an application crashes that asks if you'd like to report the crash to Microsoft. If you do, it sends a crash dump to Microsoft, where it can then be routed to the owner of the application, even if the application isn't actually developed by Microsoft.

So a lot of developers in the know have designed their applications so that unrecoverable errors actually purposely cause the application to crash so that they can get a dump from WER. One of the standard ways of doing this is simply wrapping your code in a catch at the top level and then calling Environment.FailFast to crash the process.

The problem is that sometimes the stack is destroyed in this process. Note that I didn't say the stack trace -- the stack is destroyed. You can see this if you catch and rethrow an exception. The locals from the original exception are gone, so now the dump is far more difficult to debug.

Exception filters let you get around this because they don't actually pop anything, including the exception, from the stack, so if you FailFast, you crash with the full stack of the process.

A number of .NET developers had previously figured this out and were doing a bunch of nasty stuff to get this behavior, like including a VB net module with an exception filter fail-fast, or ildasm/ilasming their assembly. We tried a bunch of these methods on the compiler and they were all a source of many really obnoxious bugs, so eventually another compiler developer and I just said "screw it" and implemented exception filters in C#. All the bugs went away and we lived happily ever after.

Oh, and now exception filters are in the language.

-----


Main purpose of this mechanism is ability to not catch some exceptions at all so that full state of memory (primarily stack itself) is preserved in crash dump or for inspection in attached debugger (which seems like more useful case to me).

With that purpose in mind, wrapping your application on the top level with try ... catch (Exception) {abort()} negates any benefit that you may get out of exception filters.

-----


Honest question, I'm not familiar with C#: would putting the Log in the finally clause not have the same behaviour? That is,

  bool _operation_X_success = false;
  try {
      ...
      _operation_X_success = true;
  } finally [
      if (!_operation_X_success) {
          Log("blah blah");
      }
  }

-----


The finally clause does not have access to the exception details, as it executes regardless of whether there is an exception or not. You can't do "Log(ex);" in the finally block. And you would want to put the exception into the log.

You also need a boolean and a few extra lines of control code as your example shows.

-----


>You can install Visual Studio 2013 Community Edition,

If you prefer to use the compiler and build system at the command line and you're only interested in managed development (i.e., C#), you can download the Microsoft Build tools package[1], which contains the compilers and MSBuild for headless development.

[1] http://www.microsoft.com/en-us/download/details.aspx?id=4493...

>> Are these tools usable without requiring GUI involvement - i.e. remotely?

Yes, I do most of my building on the command line. Editing, of course, is in VS, but I've also had fine success with Vim.

-----


Modern economic theory assumes all human beings are rational.

Citation needed.

-----


This doesn't deserve a downvote. While rationality is generally assumed, that's not universal. For example, Mises, in Human Action, explicitly discusses the problem, structuring his argument such that people must be considered black boxes that do what they do. Even any given person himself may not actually understand why he's doing something, or even what his actual preferences are.

-----


Mises is also an Austrian which, as a school, is often at odds with mainstream economics.

-----


Modern mainstream economic theory

-----


Nope, it's in.

-----


Meno was written by Plato.

-----


From what I gather (mostly through blog osmosis), you kind of fell into that career through the experience you had marketing BCC. How would you suggest someone do this intentionally, and in varying specialties?

That is, how do you decide to specialize in a marketable niche? Sure, if I already knew the marketing business I could probably worm my way into doing marketing contracting. Similarly, if I were an expert in cryptography I could start fielding requests.

What if, however, I'm just a proficient developer qualified in relatively mainstream technologies. By simple analysis of economic principles, I'm not highly valued due to the availability of general talent, so I have to subspecialize in some valuable niche. But how do I choose that specialty ahead of time? I can always choose an arbitrary specialty, but it's possible the demand isn't there.

My specialty, for example, may be in compilers, but I have an inkling feeling that being able to untwist some truly horrific legacy Win32 COM garbage may be the more lucrative endeavor. How do I test these theories without wasting a huge amount of time and money?

-----


How do I test these theories without wasting a huge amount of time and money?

Take buyers and sellers of technology services out to coffee and ask what they buy/sell and what they would buy/sell but for the impossibility of finding it in the market.

For example, you could take me out to coffee. It's no secret what I would tell you there, since it is practically in 50ft tall fire letters on my blog: When I was consulting, I made systems which made software companies lots of money, most typically by applying engineering tactics to marketing/sales ends for them. The prototypical deliverable was "Your SaaS app now sends a lifecycle email campaign." My sweet-spot client is a software company with $10 million to $50 million a year in annual sales. (There exist hundreds of these, most of whom will never even be mentioned on HN, in any context.) I am not particularly a supergenius with copywriting -- I just apply a bit of formula, horse sense, and personal experience with experimentation, and it works much of the time. I picked it up with a bit of reading and a lot of doing. Do I think that the average HNer could do this 6 weeks after having announced an intention to seriously start doing this? Yes. Can my average consulting client find someone to do this full-time for them? No, not for love or money. Do I think this niche would support a consultancy full-time? Yes. This tiny little sliver of the global economy would support ten clones of my consultancy, selling 30 weeks a year, without coming close to satisfying market demand for this service.

Price is a signal that the market generates to cue potential service providers that there exists unsatisfied demand for a service. The fact that the market does not clear in e.g. marketing technology or cryptosystem verification or what have you, even at rates in the $20k+ a week region, should signal "Well, that would be a lucrative practice to be in."

-----


It boggles my mind that you say the average HNer could do this in 6 weeks. Not in a "I don't believe you sense" but rather in a "that's so outside of my mindset that it doesn't compute."

And this is coming from someone who remembers reading stuff from you on Joel's Business of Software forums, so it's not like I haven't seen the full path from BCC to consulting to AppointmentReminder . . .

Personally, I fall into the trap of thinking, oh, I couldn't do that unless I master <insert obscure tech at the Knuth level here>. Which is clearly just not the differentiating skill here . . .

-----


Are you a younger adult? One thing that may surprise you with a decade or so behind you is how much of the big stuff was only ever a few solid weeks of pushing away.

Building and running a company worth lots of money when we sold it, yes, took 8 years. But getting the company into the right trajectory to do that --- fits and starts, blind alleys aside --- was nothing like that much work.

Some things take "10,000 hours" to get good at, but a lot of really valuable stuff takes more like 100.

-----


I'm actually older than most HN'ers. But a bit of a "late-bloomer" to being paid as a hacker.

Just didn't ever know that entrepreneurship was an actual option for people. Coming from a risk-averse and somewhat fatalistic family/peer group wrt work/career control hasn't helped.

One of the best parts of HN is actually reading contributions from people like you and Patrick that break down what are frankly self-limiting thought patterns.

-----


Isn't the fits & starts & blind alleys the actual work involved in getting the company onto the right trajectory? Empirically, the vast majority of time spent in startups is in that category, and if someone has figured out a way to reduce the time, you'd think they'd be rich by now. (Okay, you could argue that YC is a good example of an organization trying to systematically reduce the time spent getting a company on a breakout trajectory, and they are getting rich off it. But even then, a majority of YC startups never make it.)

-----


> Do I think that the average HNer could do this 6 weeks after having announced an intention to seriously start doing this? Yes.

It's statements like this where I very carefully consider tossing my day gig aside and committing for 12-16 weeks. Just to see if its true.

-----


You make it sound so simple, but how did you find your first customer?

>Take buyers and sellers of technology services out to coffee and ask what they buy/sell and what they would buy/sell but for the impossibility of finding it in the market.

How do you even know who those people are?

-----


My first customer was someone I knew from the Internet, who had a clearly achievable path to a programmer making him money. Without spilling his beans: he ran a decently sized business doing something on the Internet and was not a developer. There were some fairly obvious things about that arrangement which I could fix. I fixed them.

Thomas' company was, IIRC, my 2nd or 3rd client. He knew me from HN and the ability to talk about a topic of interest to his business over a cup of coffee. Take a look at his writeup of our conversation. You can reasonably assume that our consulting gig involved humming similar bars.

As to who in general buys programming services: go to meetups or events. Talk to people. If they buy, problem solved. If they sell, ask who (in general terms, if you're uncomfortable) buys from them. To a first approximation, everyone who has ever hired a programmer will again, at some point in the future, again hire a programmer. Same goes for consultants, etc.

If you just want to learn about realities of industry work passively, doing it for a few years is also an option. After you've built CRUD apps in a non-tech employer for 6 months you should have a 98% accurate mental model of which businesses routinely buy software in a fashion other than available-totally-off-the-shelf.

Another heuristic you can use is that one white collar employee represents $200k a year in revenue and that anyone with $10 million in revenue probably could benefit from custom software development.

-----


If any of the other ones are public, which did you like best? IIRC, Mondrian was good, but not great.

-----


From best to worse, in my experience:

1) Google's current internal one

2) Gerrit (open source, to be used by Go)

3) Google's old one (Mondrian)

4) Rietveld (open source, but run for free at codereview.appspot.com)

5) Github

I would totally suspect that Phabricator or Review Board would be well above Github (as are 1-4 in my list), but I don't know where. I have little desire to use or explore new code review systems at this point. Four per day is enough for me at the moment.

-----


In case you do want to try out another one at some point, I built https://reviewable.io to take some of my favorite features from Google's internal tool but integrate seamlessly with GitHub.

-----


Review Board isn't as good as it could be. Sometimes it's diffing tool provides far too much noise to be useful.

-----


Mondrian is the best code review tool I've ever used, but I'll admit that could be damning with faint praise... I'm very curious to hear what the better options are, because we use Github at my current company and I would go back to Mondrian in a heartbeat.

-----


So I guess the pitch is: imagine C# async/await could be "just a library", and other contexts that you wanted to handle similarly could also be a library, and the resulting functions are first-class citizens in the type system (no awkward choices of whether a particular function is async or not, you can handle that generically).

That's true in F# -- async is just a library in a computation expression.

-----


Is the given text your attempt at eliminating reserved keywords by using nonsense as keywords?

Other languages have simply decided to use contextual keywords, which preserves familiarity and flexibility.

-----


Good lord, no! Hoon has no reserved words at all.

The nonsense words are all names. This is entirely a style choice. The actual name syntax is roughly Lisp's - for instance, (my-long-function arg1 arg2) does the same thing (roughly) in Hoon as in Lisp.

In the "lapidary" Hoon in which most of the kernel is written, facets (variable names, roughly) are meaningless TLV strings, usually CVC (consonant-variable-consonant).

The user experience is much the same as with Greek letters in math: you remember the binding between symbol and semantics if you know the code you're looking at. If you are learning the code, your first task is to learn that binding. Once you know the code, there is no quasi-semantic intermediary - a meaningful name - between the symbol and the concept.

I think our small sum of experience with this daring idea is that sometimes, it works better than other times. Basically, TLV naming is appropriate for code that is simple, but not trivial. (Trivial code, like "++add", is "ultralapidary" and gets OLV names - like "a" and "b".)

Ideally all of the Arvo kernel and Hoon self-compiler would meet the TLV standard of quality. All of it is written this way, though. In general, if you should be writing lapidary code, you know it, and if you don't know you shouldn't. (And should use more or less normal names as in any Lisp.)

-----


In the "lapidary" Hoon in which most of the kernel is written, facets (variable names, roughly) are meaningless TLV strings, usually CVC (consonant-variable-consonant). The user experience is much the same as with Greek letters in math: you remember the binding between symbol and semantics if you know the code you're looking at. If you are learning the code, your first task is to learn that binding. Once you know the code, there is no quasi-semantic intermediary - a meaningful name - between the symbol and the concept.

Have you been reading a lot of Heidegger or was this an independent decision?

-----


The latter. :-)

-----


Do you have any examples of what "non-lapidary" Hoon might look like?

-----


I'm not sure much strictly non-lapidary hoon exists, but for samples marginally less lapidary than the kernel, I would like to point you to a simple algorithm translation at https://gist.github.com/MichaelBlume/17a227cc839f52f68c97, and the twitter library /main/lib/twitter/core.hook in the standard distribution.

-----


Please define "TLV", "OLV", and "lapidary".

-----


Three-letter variable, one-letter variable, http://www.merriam-webster.com/dictionary/lapidary.

-----


Three/One Letter Variables.

Lapidary:

(of language) engraved on or suitable for engraving on stone and therefore elegant and concise.

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: