Slashdot Mirror
Microsoft May Back Off of .NET Languages
An anonymous reader writes "Though Microsoft had initially made a commitment to create versions of dynamic languages that are customized for .NET, recent reports make it clear that the company may be stepping back from this plan. Much early speculation on this change in focus comes from Jim Schementi, previously the program manager in charge of Microsoft's implementation of the Ruby software known as IronRuby. Schementi reports on his blog that the team dedicated to working on IronRuby has decreased to one employee. According to Schementi, his departure from the company came as Microsoft began to display a 'serious lack of commitment' to any .NETized dynamic languages, including IronRuby."
So, Oracle are suing Google and making the JVM a less viable platform.
And Microsoft are pulling back on resources for IronRuby.
Looks like it may finally be time for the LLVM to step up to the plate and provide an open source alternative. Here's hoping...
catch (HumourFailureException e) { e.user.send("You, sir, are a humourless idiot."); }
I've been hoping for COBOL.NET.
RIP America
July 4, 1776 - September 11, 2001
Was anyone actually using them? We have Python and Perl scripts running on windows and always preferred ActivePython and ActivePerl.
"I use a Mac because I'm just better than you are."
Also one good question is - why bother with IronRuby when they already have IronPython?
Rails isn't *that* important or special anymore.
Save your wrists today - switch to Dvorak
As long as Microsoft continues to make C# and ASP.NET more capable and effective than anything else out there, I don't care if they throw IronRuby in the same trash bin as RegularRuby.
The headline "Microsoft May Back Off dynamic .NET Languages" would be better?
The truth of the matter is that it is very hard to support random other languages on VMs written for certain languages.
All these dynamic languages do one thing or another that puts a hole in your plan. Ruby with it's continuations is right up there but Python with "modify anything fundamental anytime" isn't much better. The native environment has a huge headstart.
We should all move to LLVM.
"... the guy in charge, named T. Stark, said he could do it alone ..."
With Oracle attacking Google over Java patents...
One lesson to be drawn, as suggested by Miguel de Icaza,[4] is that people should move to Mono and C# because Microsoft's patent terms are better than Sun's.
On the other hand, one could draw the lesson that it's foolish to use languages / platforms controlled by companies that use patents aggressively.
Another point is that if Google had used IcedTea (the GPL'd version of Java), they never would have been at risk from Sun/Oracle's patents.
Expert in software patents or patent law? Contribute to the ESP wiki!
Hard to argue with such a well-researched, fact-based conclusion.
If dynamic language is the same as a Functional language then MS is probably going to push F#.
Fujitsu has a COBOL.NET implementation.
>+++>+++.>+.+++++++..+++.>++.+.>.
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
"Microsoft may back off of dynamic .NET languages" would be more appropriate.
Sad to hear though, I just started a project with IronPython.
Need help treating your acne? Come here!
Oracle's legal action against Google over Android has already created confusion among developers about the future of Java as a platform. And, if Oracle is to able to stop Google from developing Android, Java will likely be avoided by any large companies for their new product. And, now this news that M$ might give up developing .NET any further adds to serve more confusion.
With the recent news, there is another programming area likely to be severely hit i.e., the development of Mono. If .NET is gonna stop, it would be difficult to justify any development on Mono. Seems RMS was right again this time in opposing Mono from the very beginning.
Only good thing this would serve in long term is more interest of developers in languages like Python, Perl. But, the present developments will definitely add so much of chaos to the programming sphere.
"Microsoft isn't dropping .NET..."
.NET for others to use. Are there any Microsoft products of importance that are programmed with .NET?
My understanding has been that Microsoft created
Mod parent up.
However..I did have to look up what a dynamic language actually is. It surely will need extensions in .NET for support, but since .NET is a interpreted language there is no basic problem. Just possible performance isssues....
Does this mean that the .NET 4.0 dynamic type will exist only for people to abuse it?
Clearly he doesn't like static or dynamic languages. Why is it so hard to get one that isn't either of those? /s
Then nothing was really lost with his departure. All Microsoft PMs do is sit in the meetings, "manage schedule", "report status", and take credit for devs' work. What's even more insane is that in some teams PM/Dev ratio is 1:1. So that remaining dev (assuming he was, in fact, a dev) has just become twice as productive, due to the decrease in the number of meetings on his calendar.
In my opinion M$ cash cow is their 'all corporations seem forced to use' OS and their 'all corporations seem forced to use' office suite.
Anything else, based on the behavior during the company's history, fades away after big announcements that it will be 'the next big thing.'
Just follow the money.
Uh, Linux geek since 1999.
The dynamic type is used by LINQ and a few other lovelies of .NET because there is no good way of figuring out what the type actually is until after the query is done.
Some programs require a certain version and will break if you have a newer version of .NET installed (vSphere Client, for one example, requires .NET Framework 2.0 but will not work with .NET 3.0).
And? There was no guarantee that all versions will be forward and backwards compatible. How is this any different than the fact that things will break going from VC++ 6 to VC++ 9? Or when there are changes to glibc that aren't backwards compatible?
While this is slightly different, creating dynamic language environments on top of .Net, language neutrality in .Net has always been a myth. It's why there is only one language for .Net in C# and how VB.Net has become totally pointless because it's merely a syntactically different but identical .Net language. After attempts at those languages failed, such as those by ActiveState, we then got reasonably API compatible Ruby and Python environments being developed on top of .Net. Unfortunately, people already had API compatible versions of Ruby and Python - the official ones - and as a result no one has seen fit to run anything under a .Net Ruby or Python environment en masse. Environments like JRuby just clouded the landscape still further. All Microsoft really wants to do is try and get a critical mass of developers deploying to their versions of Ruby and Python probably for embrace and extend, and there is no sign that this is happening. They're trying to keep on with PHP because it's still the dominant web scripting language that they need for Azure to look semi-credible, but this is likely to meet a similar fate for the same reasons.
.Net they simply didn't do. They should have created a rapid application development environment on top of .Net, free of the strict confines of C# and object oriented development, that aimed to be at least API compatible with classical VB so people merely had to recompile - as they had always been able to do. Alas, all that Microsoft did was force developers to throw lots of lines of existing code down the drain if they wanted to upgrade or either stay on the platforms they were on permanently or convert their applications to web based ones, which many did.
.Net.
The one environment that Microsoft should have created on top of
Microsoft don't appear to have learned a thing after ten years of
You need to understand the history of web development to answer that question properly.
The earliest dynamic web sites were implemented mainly in C and C++ by software developers who practiced the craft first and foremost, and treated web development merely as a particular application of their software development skills.
Starting around 1996, however, things started to change. Many non-developers started getting involved with the web. Some of these people had absolutely no programming experience, and thus just couldn't handle C. They ended up using Perl instead, which was basically the only practical scripting language at the time, since it was significantly easier to use than C or C++. PHP soon arose from this group of developers, and followed its own path.
Given the amateurish origins and background of this community, there wasn't much emphasis put on security, reliability, quality, maintainability and proper language features like static typing. That's why web applications from that time period are poorly written, and full of bugs and security holes.
On the other hand, Java soon became widely adopted by business users at roughly the same time, and soon enough they started developing web applications using Java. Many of these developers were former C and C++ developers, rather than Perl developers. After ASP.NET was released, they were soon joined by C# and VB.NET developers. These applications, being written by professional developers, are often significantly better than what was produced by the amateurish PHP/Perl community.
By the mid-2000s, the Perl/PHP community soon welcomed Python and Ruby, since they were more sensible dynamic languages that addressed many of the issues with Perl and PHP. Microsoft, Sun and others tried to draw these developers over to their platform by offering dynamic language support for .NET or the JVM. That's where IronPython, IronRuby, Groovy, JRuby, Jython and other language implementations come into play.
Given the history of web development, dynamic languages became widely used mainly out of ignorance, and have remained widely used due to continuing ignorance. There's no technical argument in favor of dynamic languages. They're just used because their users and proponents often don't even know about how much better and easier static languages make the development of both small and large applications.
Where I disagree with you is that you seem to think Microsoft killed old-school VB/VBA development and forced a generation of terrible developers to move, however relucantly, towards object oriented programming by accident.
I know there's no guarantee. I'm just bitching about it. It's just that .NET is the only thing I have had these type of problems with.
Sir there is no mention of pancakes and without pancakes you have no arguement.
You really shouldn't be a sysadmin if you can't cope with the concept of the .NET runtimes.
It's simple:
- If you have an application written for .NET 1.x, you need the 1.x runtime and libraries installed .NET 2.x, you need the 2.x runtime and libraries installed .NET 3.x, you need the 3.x runtime and libraries installed .NET 4.x, you need the 4.x runtime and libraries installed
- If you have an application written for
- If you have an application written for
- If you have an application written for
3.x actually uses the same runtime as 2.x, but it's still as simple as just using the same package as the version used by the application you want to run.
What's more you can have all of them installed at once, and better still you can deploy them via WSUS so it's really no effort. .NET is a runtime and the .NET library provides a set of functions and features that are common to many applications. This means they only have to be deployed once and all .NET Applications can use them rather than having these features re-written for every application that might need such features.
But again, if you don't know this you really shouldn't be administering Windows systems, it's been a core component of Microsoft's vision for about a decade now.
(vSphere Client, for one example, requires .NET Framework 2.0 but will not work with .NET 3.0)
I call shenanigans. .NET 3.0 is just .NET 2.0 with a few additional libraries added. .NET 3.5 is .NET 3.0 with a few more libraries and a new compiler.
What I'd guess happened is you unknowingly installed .NET 2.0 SP2 with .NET 3.0, and THAT is what broke vSphere. Sucky software is sucky.
Karma: Poor (Mostly affected by lame karma-joke sigs)
Nope, it definitely wasn't an accident so I wasn't implying that. The purposefully did it. Quite why they did it I cannot fathom because it's just hurt and fragmented their developer base that grew to an extremely critical mass during the nineties. Maybe the MSDN guys got greedy and thought they could make money from getting people to rewrite everything, I don't know.
I know people sniped at VB, but the fact is that probably billions of lines of code are sitting around written in it and it's the only rapid development platform Microsoft and Windows has. Throwing that away was not a smart move.
Microsoft is a company that is trying to point in all directions at once. This wouldn't be the first idea they have poured time and effort into, only to drop it. I am sick and tired of having to learn new development techniques just because Microsoft thinks that this year MFC/WPF/XNA/.NET/C#/F# is going to be **IT**, skimming through thousands of completely unhelpful reference pages on MSDN that merely hint at what functions/objects/libraries/tools are supposed to do but point to other pages in circular references worse than any 1990's porn sites.
Programming is supposed to make life easier, not harder. Microsoft is the expert in obfuscated standards, obfuscated libraries, and especially obfuscated documentation. It's a wonder they get anything done at all.
Seven puppies were harmed during the making of this post.
And this is why I believe there should be more people supporting the Parrot VM.
It is already usable and could support a lot more languages decently with better community support.
A website has to be up 24/7 and that's only really achievable when there's really no possibility of the app and language taking the server down (although it was tough in the early days with Perl/PHP). Web required rapid prototyping and deployment (inherent to HTML) not achievable with pure native under the Apache server model. Also, the quality of the site's "developers" required a lot of "hand-holding".
Since then, it's now a legacy tradition along with a lot of "growing up". Mega-websites are now complex apps written in many custom frameworks that could be a dynamic language with native plugins, Java, server embedded runtimes, or entirely native.
Speed (site and development) and price has been the primary evolutionary selectors depending on the sites' needs.
"... if Oracle is to able to stop Google from developing Android, Java will likely be avoided by any large companies for their new product. And, now this news that M$ might give up developing .NET any further adds to serve more
confusion."
.NET, or any other mostly proprietary language
methods, is that a company wanting a virtual monopoly can drop support for
proprietary methods and put smaller software companies out of business.
.NET languages and Java are easily
de-compiled. That makes is possible for coders from a software company that
wants to keep a virtual monopoly to discover how smaller companies have solved
problems.
The advantage of
Byte-coded languages like the
I understand that there was an order from Sun top management that no Sun products be developed in Java.
Remember, Microsoft stopped developing FoxPro, and didn't provide any escape path. At one time, Microsoft said there were 1,500,000 FoxPro developers. A few years later, Microsoft stopped developing FoxPro.
Microsoft killed the XBase languages by competing successfully with them, putting quirky features into FoxPro that were not part of XBase, and then killing FoxPro without providing libraries so that FoxPro programs could be moved to C++.
TURTLE.NET?
(or if you prefer, LOGO.NET).
(Summary of what I'm replying to: It's Google's fault, they should have paid the licence fee.)
Problem is, if Oracle can sue Google, they can sue anyone. What if there was GNU javavm, or what if Red Hat decided to distribute the Dalvik virtual machine?
I would, however, understand if Oracle told Google to stop using the "Java" name and trademark.
Expert in software patents or patent law? Contribute to the ESP wiki!
...
You're not an admin, at least not what qualifies as an admin where I work. Here you have to know what you're talking about to be called a sysadmin.
The vSphere Client bug you are talking breaks due to a patch that is unrelated to .NET. Its an MSXML problem, not .NET. You can install every released version of the .NET frame work on the same machine and they do not collide with each other, each app will use the one its designed to use for. if vSphere needs the .NET 2.0 frame work it will either find it and use it, or it won't start. It WILL NOT use the 3.0 framework instead.
Some programs don't install it because at this point ... how could you not have it? Its the new VB runtime, its on Windows update and has been so long that I barely remember that it went public after XP. Do you want the 8 or nine tiny utilities I distribute that are between 75k and 200k each to turn into 21 meg downloads because I included the .NET framework with them? No, that would be stupid.
Don't call yourself an admin. You aren't. 8 years after a tech is released that is used in all sorts of apps and you have no clue how it works.
Just because you can point and click in the Windows GUIs doesn't make you an admin, my dog can use the Windows GUIs to do 'admin' work. Christopher Reaves could use the Windows GUIs to 'admin'. But ... none of you are actually admins just because you can point and click.
Yes, stupid windows point and click fucktards that call themselves admins freaking piss me off, most of my day consists of having to figure out how tards like yourself screwed up your own machine or didn't follow directions so now I have to fix it.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I'm not saying I can't cope with it, I'm just saying it's a pain. I'm sure a lot of has to do with the fact that I'm not a Windows admin. I'm a Linux admin, so it's something I only come across every so often. Just about every sys admin I have worked with or have met has an overall negative opinion of .NET. That goes for Windows guys too. I have never heard any one of them say "Thank you Microsoft for blessing me with .NET".
Maybe the thing that has always bugged me is that you have these different "versions" that can all be installed at the same time. I understand why it might be necessary, it's just slightly counter-intuitive and not how one expects versioning to work.
Where I disagree with you is that you seem to think Microsoft killed old-school VB/VBA development and forced a generation of terrible developers to move, however relucantly, towards object oriented programming by accident.
I just need to tell you that it takes more than programming in an object-oriented language to change a programmer's code style.
"... SQL Server 2008 (the core has a dependency, while the additional services are also largely .Net based these days, including Reporting Services)."
.NET, such as ADO.NET, or are there large parts of SQL Server programmed with .NET?
Does just a minor part of SQL Server 2008 use
Then your experiences with being a sysadmin must be severely limited or your a crappy sysadmin if you can't handle something so simple.
I do very little Windows work. I'm a Linux admin. I keep a Windows XP VM to manage my Xen and VMware servers. vSphere worked fine on it until I had to install .NET 3.0 on it a few months ago in order to install an IBM SAN management tool. Maybe it wasn't directly related to .NET - I didn't look into it too much. It was much easier to just make a new VM specifically for vSphere
I don't care how fucking old the tech is. If I rarely need to use it, it's not high on my list to spend time learning about.
I just need to tell you that it takes more than programming in an object-oriented language to change a programmer's code style.
Absolutely. I didn't say most of them moved very far. :)
Interesting that having just read this I go over to ironpython.net and find it's out of action, and seeming that Microsoft (admin and technical contact on the domain name) hasn't paid their hosting bill. :P
Nope, it definitely wasn't an accident so I wasn't implying that. The purposefully did it. Quite why they did it I cannot fathom because it's just hurt and fragmented their developer base that grew to an extremely critical mass during the nineties. Maybe the MSDN guys got greedy and thought they could make money from getting people to rewrite everything, I don't know.
The impression I've always gotten is that, basically, they didn't want to keep supporting it. Maybe not Microsoft-the-entity, but the people who built the tools and things that were used to develop it or that interfaced with it. VB developers may have had no shame for what they were, but I kind of think the guys at Microsoft who were supporting them did (or wanted to build something cooler/better/etc.)
I don't think a desire for rewrites was it -- the old-VB -> VB.NET conversion tool that comes with Visual Studio has exceeded my expectations whenever I've needed to update an old VB project. It's not perfect and it has some blind spots, but it's pretty good for what it is.
I know people sniped at VB, but the fact is that probably billions of lines of code are sitting around written in it and it's the only rapid development platform Microsoft and Windows has. Throwing that away was not a smart move.
I disagree with you here, or maybe we just have different ideas of what RAD is; I don't think throwing together a quick-and-dirty app with, say, modern Visual Studio and VB.NET is measurably harder than doing the same thing with VB6. If anything, out of the box controls have made it even easier -- VB didn't even have a datagrid at all until, what, version 6, and that's something that probably most apps you'd want to RAD would want to use.
Sure, elitist developers (sometimes, I admit, including me) that used to bitch about VBA developers moved to bitching about probably those same people as web developers that just 'slapped a dataset on a page', but I don't think that kind of task got any harder.
apparently there was abit of a battle inside Microsoft - where you had 2 camps, one in support of backwards-compatibility (the Raymond Chens), and another in favour of throwing out the old cruft (the MSDN guys)
It seems the 'MSDN guys' won, and then went too far so a lot of simple migration options were ignored in favour of the 'total rewrite'. We all know how well those turn out for most companies, but in this case, it was Microsoft's customers who took the hit, not Microsoft. MS didn't suffer at all, Office remained written in C++, Windows remained written in C++ (see the threats made to Richard Grimes when he publicised the lack on .NET in Vista)
as the flagship Microsoft web language? Hey, it's lasted longer than any of the .NET languages!
> You only get a patent grant if you provide a full J2SE implementation,
That might be the general case for Java, but for the GPLv2'd version of Java distributed by Sun/Oracle there's additionally the protections granted by GPLv2.
OpenJDK is distributed under GPLv2, and sections 6 and 7 say that if you can't pass on the four freedoms, you can't distribute. It is distributed by Oracle, which means we all get the four freedoms, so a modified version, or a subset or superset would be safe.
Right?
Expert in software patents or patent law? Contribute to the ESP wiki!
What I find interesting about this is that it makes sense to me from a MS perspective.
MS doesn't want Ruby to run on the .NET Framework, because that would make the .NET Framework "just another run-time" that could be swapped out with the MRI "C" version or the Java JRuby version. They want the features of Ruby (and other dynamic languages) without the ability for applications to just jump off the platform.
So I expect MS may try to create a new dynamic language that can only run on the .NET platform. All about lock-in. That's what they did with F#. It's a syntactic ripoff of OCaml but with new changes that can't leave .NET.
Embrace, Extend, Extinguish.
-Mark
REXX.NET, GWBASIC.NET and LOGO.NET. While we're at it, please find a way to add 360ASM.NET because I feel like being challenged.
Microsoft management knows full well that the only way to stay on top of their huge bloated codebase and architecture is to continue along the path of managed code. The only thing they're not fond of are dynamic languages, pure and simple. Support for dynamic languages was added to the .NET runtime very late in the game, and begrudgingly at that. Their current development and runtime environments rely on huge amounts of auto-generated boilerplate glue without which the simplest tasks wouldn't be possible.
The reasons for this are probably largely historical, because there are still a lot of people from the old COM days working at MS. There are fact-based arguments as well: Dynamic languages tend to be more concise but are more difficult to automatically evaluate and optimize, especially considering the way Microsoft is relying on interface contracts and access policies (all of which are either generated by static language code or in turn serve to generate such code). Besides, none of the teams working on those much-needed tools and design-helpers wants to be put out of a job, so of course they have to stay firmly committed to their huge heap of statically generated code.
A few years ago some Microsoftie told me about a new research OS they were working on, it was completely .NET-based and probably still reflects how MS would like Windows to be if they could start over from scratch today. I believe the project's name was Singularity, I don't know if it still exists. Anyway, the whole point of the OS was its completely static architecture. There was no support for dynamic languages, all executables were statically linked and completely rigid. There was no self-modification allowed for any application and as far as I remember applications couldn't even dynamically load libraries at runtime. So, in a way, they already made clear which road they are going to go down. Dynamic languages aren't in the mix anymore, but managed code will stay around for a long time at Microsoft.
I draw this amazing conclusion based on the trends from http://developers.slashdot.org/comments.pl?sid=1753576&cid=33241516 but using just last 12months and comparing c#, python, java, and ruby.
So Microsoft decided to stop pouring money into something that it can't sell and which competes with products it can sell, and that will likely be completed anyway for free by people it doesn't have to pay.
Well, color me shocked. Here I was, thinking Microsoft was a charity, and now I find them acting like a notoriously cynical and rapacious megacorporation. Who'da thunk it?
Proud member of the Weirdo-American community.
I've never used Ruby or seen its continuations, but it's worth mentioning that C# has a "yield return" statement used in IEnumerator to return a value and save the current execution state in the enumerator object. This allows the the next call to the enumerator to restore the state, so it's obvious that you could implement a setjmp/longjmp with yield return plus try/finally to invalidate the jmpbufs when the calling function returns.
Since setjmp/longjmp are possible, surely you could implement Ruby's continuations. If necessary, you could even allocate each function's call stack on the heap so that jmpbufs don't have to be invalidated when the calling function returns.
Maybe Microsoft wants to further concentrate on the .NET dynamic language equivalent?
Tired of my customary (Score:1)
It exists. It's a cool site if you're into D&D and shit.
I would not be too surprised if MS stops pushing .NET in near future and instead pitches "new and improved" stuff. Totally incompatible with .NET, of course. I believe this is their way to keep windows developers busy re-learning new ways to do old tricks and too busy to look at MS competitors. .NET is 10 years old now btw. Remember VB6, DDE, OLE and WIN32? Yea, I do.
Goodness me. If you think that code converter was, or is, good enough to convert any sizeable project out there then I have to question your motives really. The thing was a sad joke.
There are many programming tasks that just do not need the kind of object-oriented overhead that .Net and C# requires. The latter is a matter of component support with nothing to do with VB itself. A DataGrid appeared in VB5, well, a decent one anyway and there ended up being two or three. If you didn't use VB, well, you had to pretty much write your own so it wasn't like there was alternatives.
There is another .NET language that is fundamentally different to C#: F#
Well, we all may not like it, but how does these 'extras' help Microsoft's core business? They aren't around for us, they are here to sell products and make money and spending time/resources on non-products dilutes their resources.
Its too bad too, with 2.0 i was just starting to mess with IronPython. Glad i didn't spend too much time on it.
---- Booth was a patriot ----
Read Joel Splosky's "How Microsoft Lost The API War", particularly the "The Two Forces at Microsoft" section. http://www.joelonsoftware.com/articles/APIWar.html
"too bad all the Java application servers blow on anything but Unix... so in reality... with Java you get Unix OSs"
J2EE application servers are available on Windows Server, Solaris, HP-UX, RedHat Linux (and other Linux distributions), AIX, OS/2, OS/390, OS/400.
Are you telling me that the two Mainframe servers aren't stable? That the Linux (JBoss or WebSphere) isn't stable? And, if a J2EE server (WebSphere or WebLogic) is blowing up on Windows Server, I would really like to know.
Back up your claim, please.
Just another "Cubible(sic) Joe" 2 17 3061
and it's the only rapid development platform Microsoft and Windows has
You mean, other than Visual Studio + .net, right?
Thanks for the description. I definitely see your point. Marking a tail call to allow the elimination of a stack frame, and allow static verification.
But, mutual recursive functions that are compiled separately cannot be so marked. Of course, attempting to check for stack non-growth is probably not included -- the call can only be marked as a tail call if it is within the same source unit, and when doing the analysis prior to marking it has already been determined that no stack growth would be needed. The tail call marking can, however, be used to suppress any frame reallocation. By definition, there will then be no frame growth, as all bound variables simply have their previous binding.
Still, this appears a complicated way of doing it.
Consider:
func() { ... func(); }
can simply be replaced by:
func() { for(;;) { ... } }
and, the second case is already accommodated by the compiler. Of course the parameters may need to be rebound, without rebinding anything else. Which (since no further frames are to be created) is as simple as:
func(int p) { ... func(new_p); }
becomes
func(int p) { int p_old; for(;;) { ... p_old = p; p = new_p; } }
(or thereabouts, note that you can use the equivalent to C's "continue" to good effect). Anyway, with a tail call flag, I would assume it looks like this:
func(int p) { ... func(new_p, tail_call=true); }
Note that we are still missing somewhere to stuff the previous binding for p (old_p) on the tail call. In the "simplistic" approach, this storage is rather explicit. As far as flow is concerned, I still don't quite understand -- the compiler had to be aware anyway. So, I still don't understand why it is considered a feature.
Although I haven't really thought about it, maybe inter-method tail calls? Maybe someone with Microsoft .Net VM experience can jump in and explain (I don't have the time to plow into Mono right now).
Since I generally compile to C, and the second method requires poking the call machinery, I tend to like my original formulation. Still, .Net is a VM and not a compiler (although it does JIT compile, right?), so it's not a big deal.
(What is likely is that I have missed something, possibly obvious, and need enlightenment).
Thanks in advance
Ratboy666 - deep down and full access
Just another "Cubible(sic) Joe" 2 17 3061
wait, languages that are syntactically different but that are able to say the same thing, are the same language??
does that mean English and French are the same language?
I know people sniped at VB, but the fact is that probably billions of lines of code are sitting around written in it...
And since MS has declared that it will support the VB6 runtime for the foreseeable future, many of those apps are still being maintained and updated in VB6. Occasionally, someone requests *new* development in VB6 (I try hard to discourage this, though).
...and it's the only rapid development platform Microsoft and Windows has.
Visual Studio 2002 and later are rapid development tools as long as you stick to C# or VB.Net (e.g., there's no forms designer for MS C++/CLI). For Windows RAD outside of MS tools, Delphi & C++Builder have been around forever and they support native development, although they've changed hands (now owned by Embarcadero). Also, people tend to forget (perhaps intentionally) PowerBuilder. Some people would assert that MS Access is a RAD development tool; those people are annoying...
- T
I've never used Ruby or seen its continuations, but it's worth mentioning that C# has a "yield return" statement used in IEnumerator to return a value and save the current execution state in the enumerator object. This allows the the next call to the enumerator to restore the state, so it's obvious that you could implement a setjmp/longjmp with yield return plus try/finally to invalidate the jmpbufs when the calling function returns.
"yield return" is pure syntactic sugar on C# level. The way it's implemented, the entire stack frame of the function that has any "yield" in it is lifted to heap as part of enumerator, and the latter gets an extra field to record current state for the state machine. It's all just classes and objects on CLR (VM/JIT) level.
It's possible to implement setjmp/longjmp that way, but it would be pretty inefficient, as the overhead for putting locals on heap is high, and you pay it even if there is no longjmp. Exceptions would be a better approach.
Since setjmp/longjmp are possible, surely you could implement Ruby's continuations.
This doesn't follow, because you can only longjmp up the call stack, not down (i.e. not to a stack frame which is gone already). With call/cc, you can go to any state, even if it was returned from a function call that captured its own state.
If necessary, you could even allocate each function's call stack on the heap so that jmpbufs don't have to be invalidated when the calling function returns.
Yeah, you'd have to do that, and that kills performance, again.
Example?
We still have ExpandoObject, so you can pretend that you are actually writing in JavaScript when using C# 4...
Anyway, even if all (including third-party) dynamic languages targeting CLR suddenly go away, "dynamic" is still immensely useful for COM stuff alone.
Fuck 'em. After all, they did it to us, the truly faithful users of VB6 and ASP VBscript.
Now they do it to .NET developers, who are a dumber generation but who, when struck between the forehead with a two-by-four repeatedly, can finally get Microsoft's message: "Programmers? Programmers? We don't need no stinkin' programmers!"
VB(6, the predecessor to .NET) needed to die, since it was designed for a different era that's passed.
.NET family. I know it's convenient to say they did it for the money, and they may well have, but that doesn't invalidate all the other benefits of that decision.
It has no cross platform compatibility, no built-in class library to speak of, and no template support. It's object-oriented, but in a way that allows you to never make your own classes if you choose--an interesting idea to try that, IMO, fails in the long term. Its use of built-in objects is schizophrenic: strings have no methods, but UI objects do. Numeric data types are somewhat nonstandard (Integer max is 2^15-1...). Run time error logging is terrible and requires numbering your code lines manually, without offering a stack trace.
It also wasn't designed to support many tasks that became common: resolution independence, quality image resizing, taking the inverse cosine, scrolling, skinning, and data serialization all require you to implement it yourself or use third party libraries. Even Windows API calls require you to know the DLL name and method signature which, again, are found only with the help of third parties.
Some of these defects could have been addressed with future versions. However, that would have required extensions to a broken system instead of a clean design made to avoid previous faults. Some changes would have been breaking, particularly better OO support. All in all, I'm glad MS decided to let pure VB die in favor of the much better-thought-out
Has noone considered that maybe, just maybe the real reason is that Ruby is a terrible, terrible language with no good implementation and a community that's worse than 4chan and CounterStrike COMBINED?
It was a fad; fad is over. Bury it and move on to better things.
we discovered a new way to think.
but they also threw FoxPro and Visual FoxPro under the bus when they were "finished" with it. MS isn't so much about "tech" smarts - it's all about money smarts - EEE write large.
As for rapid application development tools based on .NET: Visual Studio LightSwitch
Developers might want to remember this when they try to sell you the next stolen/slightly modified language (C#...) Microsoft upper management are greedheads pure and simple - technology is just the carrot to be used to get your bucks. Anyone who has been around from the beginning of MS knows this.
(e.g., there's no forms designer for MS C++/CLI).
Small quibble: It's there in 2003 onwards.
I don't think a desire for rewrites was it -- the old-VB -> VB.NET conversion tool that comes with Visual Studio has exceeded my expectations whenever I've needed to update an old VB project.
Goodness me. If you think that code converter was, or is, good enough to convert any sizeable project out there then I have to question your motives really. The thing was a sad joke.
That was my experience as well. When I ran my fairly small VB6 app through the converter I immediately thought "Oh shit, I might as well re-write the damn thing". Which is what I'm doing, slowly anyway.
If you were able to port it over, most of it would be pointless. All you've done is gotten the same old code in a new IDE, you've just ported over all the language deficiencies you had before. There are whole design paradigms that are different in .Net, and just moving the code over doesn't make them available to you. At the very least you'll have to re-factor the hell out of it, and it will be very similar to just re-writing it.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
ASP.Net is still the flagship web language, is it not? I didn't think that changed. I thought all the Iron crap was just catering.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
Sorry (reply to myself) -- it's a tail call, so by definition, we don't need to keep "old_p" around. Since the exit point MUST be the end of the function, simply because the return point itself must be rendered irrelevant to the call. Therefore, there is never a need to restore the old binding for p, and we can simply assign (p = newval) prior to the loop back.
My bad -- I must have been in an alternate reality while typing the above.
Ratboy666
Just another "Cubible(sic) Joe" 2 17 3061
I could argue that .NET is already a rapid development platform, a Java-like bussiness platform, and a getting-more-and-more-dynamic language: .NET the same way as in VB, you can; you can create huge objects full of unrelated functions, lots of global variables, and don't use any of the more advanced functionalities, and you will have nearly the same. If you need variants, you can have them in the latest releases.
- If you want to develop in
- The Java-like is trivial.
- Dynamic language: a lot of the latest and coolest features added to C# are borrowed from dynamic languages, and I'm pretty sure that next releases will add more and more of them. In fact, I think the main reason they killed IronRuby is they can give C# most of Ruby's flagship features, so, what's the point?
Ugly side of this: C# is becoming a huge multiheaded language which different programmers use in a complete different way; soon, we will end in a "worse than Perl or C++" scenario in which we will be unable to understand other people's code because it uses a totally different set of features we have never ever used or heard of.
MSFT doesn't write any of their native apps in C#, so it makes one wonder why spend all this time writing these interpreted languages in the first place? It always seemed to me that Microsoft would want to detract people from writing C / C++ code so their own code would run faster without interpretation performance penalties. Similar to the way MSFT threw a curveball in the 80's when they push out GWBasic on their customers to fool them into thinking it was a real programming language, thereby stifling innovation and competition. Rather than release MSC++ or MASM as the default compiler, they put out GWBasic. It's all about smoke and mirrors over at MSFT.
Rather than get into an age-old static-versus-dynamic holy-war here, let me suggest that it depends on the kind of app and environment. If your app needs to be nimble, quick-to-market, and has relatively few final end-users; then use a dynamic language. If it's accounting, safety, legal, money-related, or will be packaged and shipped to thousands of customers, then use a static language.
Table-ized A.I.
You're right, of course. I always get the Visual Studio native vs. .Net C++ capabilities confused because I'm much more frequently using C++Builder. Thanks for the correction.
- T
There used to be a company called VB-Extra's that sold 3rd-party datagrids and other widgets with all kinds of fancy variations.
Table-ized A.I.