IronPyton, IronRuby, IronLisp, IronScheme, Lua/Nua. There are other non-dynamic ones out there too, like F#.
What MS did was NOT to pick one language to focus on. They built some really nice dynamic language support on top of the.net clr and runtime, that allows all these different non-strongly-typed-languages work well on top of.net.
They DID hire some of the notables from the Ruby and Python camps to run these projects inside MS.
I hear what you're saying, but its really not trend-whoring. The whole DLR is quite an excellent approach to dynamic languages on top of the.net clr runtime. You'll see some similar things from Java in the next few years.
The fact that you see so much about Ruby is just because Ruby is the 'new hotness' at the moment, but this too shall pass.
For what its worth, Silverlight against REST works great.
You lose access to some of the tools that you can use with proper SOAP (xsd.exe to pre-generate strongly typed result sets, LINQ, etc) but it does work quite well. And all nicely asynchronous, with good support in the language.
Mind you, you can tell from the tools that full SOAP is the preferred method, but REST is covered quite nicely.
As other's below have said, you dont have the full.NET framework in silverlight, only a subset.
In addition, all.NET apps run in one of various security models (partial trust, full trust, etc). As an example, only certain types of apps can be run on a shared MS windows asp.net server, because you dont want to give them full control to the OS.
Another one is 'click once deployments' where an entire.NET app gets deployed from a UNC or webserver, and runs in a low trust model, in a sandbox, with almost no privs to the local system.
MS has actually had an excellent security record with their.NET security model, with respect to successful breaks of it.
I'm really not trying to wage a war here... just trying to have more good discussions.
The problem I run into is that it seems to me that what you lose in dynamic languages will really come into play in larger projects (hundreds of thousands to millions of lines of code). Unfortunately, I've never done a project that size in a dynamic language, and I dont see that I ever will.
So this kind of discussion helps me get information which it would be hard for me to synthetically create experience on.
There's no question in my mind that Python/Ruby/whatever can be hugely faster to develop in small utility scripts, things where you dont even have a business domain to model, much less a strong separation between the business services engine and various different presentation fronts.
But having to read the inner code of a method on an object, to determine what kind of thing I need to pass in, because its just not possible to specify that in the method declaration itself just kills me. Breaks one of the fundamental concepts of OO, Encapsulation. Anytime you're forced to look into the source code to figure out what kind of thing to pass... thats just a bad smell. That also forces you to base your code on the other code's implementation, rather than its public contract, which is also a bad smell. It's not as bad as fully depending on certain internal data structures of the other object, but its close.
Anyway, really not trying to wage or start a war here... just trying to gather some feedback from those who've worked on larger projects, who can speak to some of these issues.
For someone who admittedly doesn't know much, if anything, about Smalltalk, you're certainly quick to tell people what Smalltalk can and can't and does and doesn't do. Please feel free to do your own research. Thats certainly not my intention.
I'm just a little tired of people coming in here and saying 'but Smalltalk could do it', even though at least some of the things these people claim Smalltalk can do are logically impossible to know ahead of time.
If something is unknowable, then the Smalltalk IDE cannot know it.
I also notice that 100% of the people that claim 'smalltalk can do it' are completely unable to answer how it supposedly solves some of the fundamental tricky problems with dynamic languages.
I also notice that though you're the one that brought up Smalltalk in the first place, all of your responses have been very light on detail or specifics.
I also notice that in every case where I present very specific scenarios where I dont think its even physically possible for something to be knowable, you've never once responded to them, other than 'but I know it can'. No details, no specifics, no useful debate, just 'I know it can'.
You're right in that I havent had the opportunity to gain a deep understanding of Smalltalk yet. I own (with some partners) a software and technology startup, and dont have a huge amount of free time at the moment. But I will catch up to my 'new languages to learn' list within the next year or two, and Smalltalk will certainly be on it.
You shouldnt have to unit test for syntactical errors though, thats just crazy.
You do unit tests to prove behavior, not correct syntax. Theoretically, given equivalent functionality, you should have the same behavior based unit tests in Ruby and Java. But in Ruby, you've got to do more unit tests, because you've got to test stuff that in Java the compiler would find for you.
And if I've got to unit test every single call of every method, to make sure that the values passed in as method parameters will respond to the expected messages? Thats just insane.
And yes, I know thats somewhat of a joke example, because no one really does that. But that means that you've just lost all of that 'provable correctness' that you would otherwise have, and have to replace alot of what you got for free with a compiler, with hand-written unit tests.
So the question becomes whether other productivity benefits outweight productivity losess, and losses of provable correctness. And of course, the answer is that 'it depends'.
I've done little apps in Java, and hated it. I've done big apps in Java (couple million lines of code, 30+ developers spread across the US) and loved it. To have to work on a project like the latter without the tools you get from the IDE would be nearly impossible.
I've done little apps in Ruby, and I liked it. Havent had the opportunity (and probably never will) to do big apps in Ruby, but my gut says that it wouldnt work out very well as the project got large.
A good example is in refactorings. When you're refactoring code in a large app that is consumed by many other modules in that app, its dangerous. It's easy to cause more problems than you solve.
But the IDEs help a great deal, by showing you instantly and unambiguously where code is broken as a result of your refactoring. It does this because it can form a concrete AST.
With a dynamic language like Ruby and others, you're forced to use text-pattern-matching, which is much less reliable. And even then, what if part of your refactoring was to move a method from public to private/protected (assuming you do have private methods in Ruby, cant remember). That would be a very easy thing to miss, when you're forced to rely on text pattern matching.
With a language like Java, the IDE/compiler knows instantly. That is a big advantage.
Okay, I'm not going to give up here, because I've had so many people come back with 'but smalltalk can', yet never really explain how.
Let's try two scenarios.
1. We have a class Foo, and we have a mixed in method bar() that we only want to load conditionally.
When I'm in the smalltalk IDE, and I type Foo. does it show bar() as one of the methods? Does it show an error (or not) if I use bar() as a method of Foo.
And how is that determination made? Sometimes bar() is a valid method of Foo, sometimes its not. Which situation does the IDE assume, and how does it go about that choice?
At any given runtime execution, it either unambiguously either is or isnt a method. But until you are in a real execution of the app, with application state and configuration applied, the choice is unknown (and arguably unknowable).
But the IDE has to either show it to your or not, either mark it as an error or not. Which does it do?
2. Calling methods with parameters. Say you call a method (pass a message) on Foo, called Happy(dog), where dog needs to be able to respond to message/method 'reproduce'.
In your statically typed language, the IDE and/or compiler can tell you instantly if you've passed a value thats not compatible with the parameter.
But not in this sort of environment, because we dont know for sure until runtime, whether the value passed into Happy(dog) will respond to 'reproduce'. Given the power of runtime mixins, its arguably not possible to know whether your syntax is correct, because things change.
You say its always runtime, but thats clearly an exaggeration at minimum, and just being snarky (in your words) at worst.
Some programs are non-deterministic, in the sense that you have nearly an infinite amount of unpredictable inputs. If the IDE is going to 'run' your program all the time, in what sense is it running it? Is it making database modifications (since thats what the vast majority of software does) and reads? And more importantly, WHAT initial and ongoing state is it choosing?
Whether Ruby or Smalltalk, if you dont know for sure exactly what a variable/object is, and exactly what it cant do, then the IDE cant tell you that information, because it doesnt exist. Or rather it does exist, but it exists as a arbitrarily large set of functions, which in and of itself could be described as software.
My point in all of this (at least way back up the thread where this talk started) is that you lose so much power in a language when you take the compiler or IDE's ability to find errors away.
Not to mention the developer productivity of having to memorize or lookup every single class or method call they might ever use.
Not to mention fancy stuff like walk up the call hierarchy, do refactorings, do renames, etc. Without a proper AST, you lose your ability to do alot of very very useful things, particularly as software projects grow large.
I understand what you're saying, it just feels like such a massive step backwards in many ways, though much of Ruby is very interesting.
With that situation, even the stupidest most minor typos can be non-detectable until runtime. And even then if you are doing fancy things with method_missing, it STILL may not fail, just may do completely unexpected things.
That takes me back to the horror of 15 years or so ago when I was working with pre-'option explicit' VB. Where typos could cause completely unpredictable (and rare/intermittent) strange side effects.
That kind of thing is so hard to troubleshoot, just makes me want to tear my hair out.
I'm a little bit playing the devil's advocate here, but: It seems to me that classes should exposes contracts (ie, interfaces) that you can count on, because that creates better code in the long run. But if you have no contracts or in the case of ruby, there are contracts but you cant tell whether you've met them until runtime, that just seems like going backwards.
Well, thank you for not reading what I wrote at all.
Let me try again.
Class A is conditionally modified by adding a new method, in some execution paths.
Therefore, at runtime, there is one and only one state, so the outcome is easily determined. In some situations, it will have the new method, in some it wont. But in any one execution, it either will or it wont.
However, at design time, the state is completely non-deterministic (or at least trivially can be), since you cant predict which of the execution paths will be taken, and therefore whether the modifications are made or not.
Given that, which of the two possible future class states would the IDE/compiler show?
If you dont know the answer, its okay to say so. If its just something you've read, and you dont really know the internal mechanics of how it handles cases like this, then please just say so rather than wasting both of our times by saying 'it just does'.
Not sure I understand this, how are Lists and Hashes not first class objects in Java?
They're both objects, they both implement one or more interfaces, etc. By every definition I'm aware of, they are true, first-class objects.
I'd also love something more explanatory than: 'less-broken this' and 'less-broken that'. Can you be more specific?
For example, many people decry the int vs Integer issue, is that what you're talking about?
Given that using the natives is completely optional, and you could write huge java projects without ever touching them, except where you need to optimize by using the stack, how is this that big of a problem?
How is it worse than Ruby having this ? you can put at the end of a method, but it doesnt really mean anything and not enforced in the runtime. So its an equally optional thing, but its use is pure sugar, and its not actually seen or heard by the runtime at all.
I'm not saying that there arent aspects of ruby that are superior.... but your statements are very vague and over-arching.
Where Ruby's mutability can be used for Good is unit testing. Specifically, for creating mock objects. Thats a really good point.
Mock object code in Java unit testing can be HUGE number of lines.
It's very doable as long as you're using interfaces (everybody was using interfaces, werent they?) so you just write a skeletal mock that implements the interface and so a special wireup in Spring to inject that mock.
But that is complicated and hideously verbose.
So I appreciate your post... this is one area where ruby's looseness is a plus.
Mind you though, in Java there are some great mock & unit testing frameworks that make this problem much less of a problem.
In most languages this is hard or impossible, because it means reaching inside the execution of A and temporarily changing the functionality of B. This part of it is easy (if verbose) in Java. You just write a mock class, and have Spring inject it instead of the regular implementation when running that test. Since both the real and the mock implement the same interface, and you've coded to an interface, this works quite well, though its anything but trivial. Thats a very very common approach.
Hard to imagine Java without Spring though.... Spring has literally given Java another 10-20 years, IMO.
I've heard that said before, but I'm not informed enough about Smalltalk to agree or not.
Explain to me though how thats possible, given:
You can modify classes/methods at runtime.
You can conditionally do so, so in some execution paths the modifications exist, and in some they dont.
Given that, how does the Smalltalk IDE/compiler determine whether the new/modified method is there during design-time, given that its a conditional runtime modification?
A perfect example of this is in Rails & ActiveRecord. Lets say I have a class backed by a table that has 50 fields in it.
Why the hell cant the language/environment just let me pick from a list, instead of forcing me to memorize all 50 elements, or keep all table definitions open in front of me. Further, if I typo one, why the hell cant I tell until runtime.
Thats just an absurd step backwards in developer productivity (talking about Ruby here, I'm just not up to speed enough on Smalltalk to say whether it works similarly or not).
For instance, let's say you want to log when a specific piece of data is changed on a class. In Java, you'd inherit from the base class, override the setters, and add your logging code Actually, the smart folks on Java wouldnt do it that way, they'd either:
1. Use encapsulation, rather than Inheritence.
2. Use Spring to put logging pointcuts either before or after.
However, thats not really my point....
The language features (mixins) that you're showing here with Ruby are a double-edged sword.
They make certain things like you demonstrate very easy, but they come at a HUGE cost.
It basically makes it impossible to find whole (huge) classes of errors at design/compile time. To make things worse, you could have a conditional mixin. The result is that its IMPOSSIBLE for the IDE or compiler or static analysis tool to know whether a method exists, or I've passed the right number/type of parameters in.
Not having a fixed and knowable/provable syntax tree makes so many useful things impossible.
That sort of thing should be caught instantly, and you shouldnt have to wait for runtime errors or unit-testing failures to show up. And you shouldnt have to write unit tests to confirm syntactical correctness.
This sort of thing takes me back to the bad old days of VB w/ Variants and untyped/undeclared variables.
Frankly, I'd LOVE to have the Ruby syntactical sugar, closures, and expressiveness in a statically typed flavor of it with interfaces. I miss my interfaces when playing with Ruby. Design by contract is such a useful thing, its terrible when you miss it.
Sorry, it is HER laptop, not one of my laptops at work. LOL so you dont think its appropriate to make her non-admin on Windows, but then at the end of your post, you suggest doing EXACTLY that with a Linux distro. Give me a break.
I think the best thing is to have her do a wubi install, do all browsing from Linux and only use windows for her required coursework. Tell her anytime it don't work, give me a call. So every time she downloads some program and can't install it. I can explain to her why the spyware is bad and take her to nonags or freewarehome and show her how to find a non-spyware laden alternative. Just do the EXACT same plan, but leave her on windows. She doesnt have to learn anything new, everything works the way it always did, but "anytime it don't work, give me a call.".
Your plan was precisely the same as my plan, except you wanted to move her to a new OS for no real benefit. In both cases he's non-admin and cant install things, which solves the primary problem as stated.
Like hell it is! Imagine if a company with 500 Windows XP Professional PCs could upgrade to Windows Vista Business without buying a single piece of extra hardware! Millions of PCs are still running Windows XP, and will never be upgraded because the added cost of hardware upgrades or complete hardware replacement for Vista or Windows 7 is more than the company/government organization/whatever is willing to pay. I get what you're saying, but look at it from MS' business perspective. Those businesses are already on a contract or subscription plan, so they're paying per-head per-year anyway, regardless of what OS they run. There's no demand for Vista that runs on the same or less hardware that would sell more titles. But there IS demand for the OS that has 'the next compelling feature'. In fact thats all most people talk about, is what 'features' are better in Vista to make the upgrade work worthwhile.
Imagine if home PC buyers could get a full feature, full performance version of Vista on a home PC for $100 or $200 less in hardware costs than what they need now, and with no 'Vista Capable' scandals. For laptops, the cost effects of the requirements jump from XP to Vista is even larger - right now, the cheapest $400 and $500 laptop configurations from most vendors are blazingly fast on XP, but if you want equivalent performance on Vista you need to spend $300 or $400 more. Again, I see what you're saying, but thats not the market we're in. People dont buy computers that way. They buy a new computer when they need one, or see new features that they want, or when the old one gets so slow and crappy its not useful anymore. Then they buy the computer they can afford. Unfortunately, due to a terrible 'Vista Capable' marketing campaign this resulted in people getting Vista on machines that should never have been sold with it.
What MS should have done would be to do the 'Vista Capable' thing accurately. Then for the folks who want a $300-400 computer, they would buy an XP box. And they would see the Vista boxes right next to them, costing a couple hundred more, but faster hardware and (as perceived) more features. That would be an effective differential pricing plan.
By contrast, I've sat at dozens of Vista machines (I used to install internet) and found them consistently: slow, resource hogging, confusing in layout, and unstable (call it tilt-bits, DRM, bloat, or whatever you like; the experience is what it is). Actually, I dont think its any of those (bloat or Gutmann's possibly-fantasy tilt-bits).
Based on some things I've seen and read, at this point I'm really starting to blame the OEMs.
Alot of them are just absolutely killing the machines with crapware and ancient (ie, bad) drivers. Here's an excellent article on the topic.
A clean build of Vista on a machine with well-supported drivers is fast and stable, in my experience. But I'm not the normal user.
As I've said a few other places here today.... its almost amusing.
The technology improvements MS made in Vista are quite impressive. And Vista 'should' be quite good, much like Server 2008 is quite good.
But its all been in the distribution, marketing and ecosystem development.
They crumpled and ruined the consumer experience with the 'Vista Capable' marketing campaign. Thats going to turn out to be one of the biggest nails in the Vista 'perceived-success' coffin.
They didnt force the OEMs to only sell Vista machines that performed well.
And they did a TERRIBLE job with driver manufacturers, particularly Nvidia and ATI. If you look at what causes the most bsod/bugchecks in Vista, its those two.
The drawbacks are/would have been a huge performance hit once the file system became fragmented Did you not even read the post you're responding to? WinFS didnt replace NTFS, it was a metadata layer on top of it. Therefore any issues would be orthoganol to ntfs fragmentation issues.
ever wonder why CHKDSK is still around, and has an option to run at boot? Hmm, maybe because every file system, even ZFS, need diagnostic and repair tools? If your measurement of a good file system is that it doesnt have any diagnostic or repair tools, then you're going to be waiting for a long time.
NTFS is prone to file system corruption over time Not quite. NTFS doesnt do anything to repair sector failures or intermittent read/write errors, or bus errors in systems. NTFS itself is quite robust. Nowadays, however, thats becoming not enough, hence why things such as ZFS are such a big deal that does checking at every level, and detects and sometimes repairs even hardware based errors.
Mind you, of the file systems I'm aware of, ZFS is the only one that handles this well. Dont even get me started on ext2 or ext3. Maybe Novell's systems were better, that wouldnt surprise me. Novell's directory systems were way ahead of their time. It's unfortunate that they didnt have the business acumen to survive.
NetWare volumes never needed to be defragmented, ever. To be fair, neither does NTFS except in extreme situations. I dont think, in 10+ years of doing this, that I've ever defrag'd a server filesystem. And I've never defrag'd one of my desktops.
Under typical circumstances, NTFS doesnt need defragmentation. A certain level of fragmentation is normal and desired. Where you run into problems with NTFS is when you get very full drives and within a few percentage points of 100% full. Other than that, it just doesnt come up.
It's basically a big placebo that the ignorant use. It doesnt actually help performance any under normal circumstances, but it makes people feel like they're doing something.
And don't even get me started about what happens to AD once you start to scale it up... it's embarassing how poorly it performs by comparison to even NDS - and against eDirectory it's just sad. The NetWare 5.0 servers that we are slowly migrating away from after nearly 10 years of constant availability, running dual-Pentium III processors, consistently outperform the Windows 2003 servers running on modern hardware with a LOT more memory and MUCH faster hard drives for things such as replication and file system access/rights validation and we're not even halfway done. So dont move. Stay on NDS. No one is holding a gun to your head and forcing you to move to Windows and AD. Sun even has a nice directory product, and there are open source ones as well. Why arent you using any of those?
I've got to say, if you're going to sit around and bitch about the MS solutions, but then go ahead and implement them anyway, then you're not going to get much respect for your opinions. Your actions are different than your words. Maybe you're just not a decision maker wherever you work. What are the senior technical folks doing, and why are they pushing this?
Someone must have a reason to be doing so. Novell eDirectory looks compelling on paper, but hardly anyone runs it, and Novell isnt exactly the most focused company in getting their products out there.
Agreed that its still intact, why wouldnt it be? I guess what I should have asked before is why it requires massive changes to be 'good'?
Some of the things that I see include new process scheduler, new IO scheduler, new network stack, new memory manager, major improvements for SATA with a generic driver, new bootloader, new heap structure and manager (improved fragmentation performance), and settable IO priorities (ie, ionice equiv).
These are pretty significant and low level.
I dont think its reasonable to expect a commercial kernel like windows nt to change as much as something like linux. The linux kernel folks break everyone badly alot (ie, driver writers, 3rd party authors, file system authors, system software authors) with significant changes to kernel APIS, behavior, and ABIS.
This sort of thing doesnt really work in the commercial world, as people come to rely on even undocumented kernel structures. It's not right that they do so, but if they change stuff very often, 3rd party software breaks. And the consumer/end-user only knows that it broke when they did a MS update, so it must be MS fault, even if it was completely the 3rd party's fault.
Hell, half the anti-virus companies made a big publicity stunt when MS tried to lock down certain kernel data structures from direct manipulation (ie, not through the APIs). Even though its a TERRIBLE thing to do so, MS gets beaten down in the public eye because people just dont understand this stuff.
Anyway, you're right in that it will never move as fast or as interesting as Linux kernel, but thats okay, there's place in the market for a more conservative stable kernel. But just because its isnt majorly rehauled every year, doesnt make it bad.
I'm confused about your complaint of the NT kernel. Its widely agreed to be fairly decent. Nearly all of people's complaints are in win32 or userland stuff (explorer.exe, iexplore.exe).
In addition, there were some very nice core/kernel improvements to windows in Vista. You can read about them here.
It doesnt take much research to see where MS went wrong with Vista, and very little of it had to do with technology.
As an example, go use Server 2008, which is the same core system as Vista SP1 (sans the userspace stuff). It's what Vista should have been for most folks.
I'm glad you had a good experience with the white box. The whitebox laptops I've seen have all been pretty crappy form factor, so havent gone there yet. This HP has literally been the best built laptop I've ever owned.
That being said..
Less work than it took to get Windows understanding there were two screens on the same machine. This I dont understand. In my entire life of using computers, I've literally _never_ seen or heard of windows having a problem with multi-mon situations.
It almost always just automatically detects it, and 'just works'.
The worst I've ever had happen is when switching between different environments, every once in a while, it wont pick the right profile (ie, docked to the docking station, external monitor) and I have to spend 60 seconds setting it up.
Even when it doesnt automatically set it up, configuring multi-mon on windows is the easiest thing in the world. Just line up the little boxes how you want them, set which one you want as primary, and you're done.
On that last point. It would of been a kindness to put Linux on that machine. It would keep her out of so much trouble. Linux is better for people who don't have a clue what is safe to click on on the internet. Of course, you could also just make them non-admin on windows, and set the machine to auto-update, and set them free. Even the recent flash vulns cant takeover the box in that scenario. Then they dont have to know whats safe, they dont have the power to do any harm to themselves.
For most intents and purposes, MinWin is here now, its called Server 2008 Core. You can go play with it now.
I doubt if they would EVER productize it for the desktop. What would be the point of a desktop OS with no GUI no sound and only a command line interface?
By spring 2010 they should be selling quad core 4GHz machines with 4GB ram standard. That should allow users to run the Vista kernel at a reasonable speed and even leave some of the eye candy turned on. What nonsense.
I've got a (nice) HP Compaq 8710w laptop. C2D 2.4, 4GB of ram, and Nvidia Quadra 1600M w/ 512mb of ram built in.
Yes its top end when I bought it (most of a year ago).
But you know what, it runs Vista Business x64 nearly flawlessly. Other than when booting (which I almost never have to do) it never hits the hard drive. It's responses are nearly instant everywhere. It's quite nice. And thats with search/indexing and system restore and shadow copy all turned on.
I think what you'll find is that Vista will run quite fine on lesser hardware, as long as there isnt a bunch of crapware installed from the OEM, and the drivers are quality.
WinFS was always a layer on top of NTFS. It never was intended to be a general purpose file system.
WinFS was not designed around the MinWin kernel. The MinWin kernel didnt exist in any form until well into the Server 2008 development cycle, which follows WinFS dev by like 8 years.
The Win2003 kernel was NOT used in Vista. Yes, thats where they started way back when, but Vista is a major-ver change over the 2003 kernel.
The Server 2008 kernel is not an updated win2003 kernel. It's an updated Vista kernel. In fact Vista SP1 and Server 2008 are largely the same product, with the differences being in userland stuff.
It is really unfortunate because the NTFS is horribly outdated and lacks many modern features that help find files. From a user perspective, being able to tag files with search-able information is invaluable, and is the main reason I only store my photos and non-Word documents on Linux and Mac. Actually NTFS has had arbitrary metadata built into it for more than 10 years. That feature is positively ancient. For whatever reason, MS has never chosen to productize it and write userspace apps to manage that metadata.
So interestingly, you could have done that keyword tagging and indexing on those a LONG time ago, but MS chose not to productize that stuff for whatever reason.
Slashdot Mirror
They didnt 'just pick Ruby' (paraphrasing mine).
.net clr and runtime, that allows all these different non-strongly-typed-languages work well on top of .net.
.net clr runtime. You'll see some similar things from Java in the next few years.
Look on the right hand side of the page here.
IronPyton, IronRuby, IronLisp, IronScheme, Lua/Nua. There are other non-dynamic ones out there too, like F#.
What MS did was NOT to pick one language to focus on. They built some really nice dynamic language support on top of the
They DID hire some of the notables from the Ruby and Python camps to run these projects inside MS.
I hear what you're saying, but its really not trend-whoring. The whole DLR is quite an excellent approach to dynamic languages on top of the
The fact that you see so much about Ruby is just because Ruby is the 'new hotness' at the moment, but this too shall pass.
For what its worth, Silverlight against REST works great.
You lose access to some of the tools that you can use with proper SOAP (xsd.exe to pre-generate strongly typed result sets, LINQ, etc) but it does work quite well. And all nicely asynchronous, with good support in the language.
Mind you, you can tell from the tools that full SOAP is the preferred method, but REST is covered quite nicely.
As other's below have said, you dont have the full .NET framework in silverlight, only a subset.
.NET apps run in one of various security models (partial trust, full trust, etc). As an example, only certain types of apps can be run on a shared MS windows asp.net server, because you dont want to give them full control to the OS.
.NET app gets deployed from a UNC or webserver, and runs in a low trust model, in a sandbox, with almost no privs to the local system.
.NET security model, with respect to successful breaks of it.
In addition, all
Another one is 'click once deployments' where an entire
MS has actually had an excellent security record with their
I'm really not trying to wage a war here ... just trying to have more good discussions.
... thats just a bad smell. That also forces you to base your code on the other code's implementation, rather than its public contract, which is also a bad smell. It's not as bad as fully depending on certain internal data structures of the other object, but its close.
... just trying to gather some feedback from those who've worked on larger projects, who can speak to some of these issues.
The problem I run into is that it seems to me that what you lose in dynamic languages will really come into play in larger projects (hundreds of thousands to millions of lines of code). Unfortunately, I've never done a project that size in a dynamic language, and I dont see that I ever will.
So this kind of discussion helps me get information which it would be hard for me to synthetically create experience on.
There's no question in my mind that Python/Ruby/whatever can be hugely faster to develop in small utility scripts, things where you dont even have a business domain to model, much less a strong separation between the business services engine and various different presentation fronts.
But having to read the inner code of a method on an object, to determine what kind of thing I need to pass in, because its just not possible to specify that in the method declaration itself just kills me. Breaks one of the fundamental concepts of OO, Encapsulation. Anytime you're forced to look into the source code to figure out what kind of thing to pass
Anyway, really not trying to wage or start a war here
I'm just a little tired of people coming in here and saying 'but Smalltalk could do it', even though at least some of the things these people claim Smalltalk can do are logically impossible to know ahead of time.
If something is unknowable, then the Smalltalk IDE cannot know it.
I also notice that 100% of the people that claim 'smalltalk can do it' are completely unable to answer how it supposedly solves some of the fundamental tricky problems with dynamic languages.
I also notice that though you're the one that brought up Smalltalk in the first place, all of your responses have been very light on detail or specifics.
I also notice that in every case where I present very specific scenarios where I dont think its even physically possible for something to be knowable, you've never once responded to them, other than 'but I know it can'. No details, no specifics, no useful debate, just 'I know it can'.
You're right in that I havent had the opportunity to gain a deep understanding of Smalltalk yet. I own (with some partners) a software and technology startup, and dont have a huge amount of free time at the moment. But I will catch up to my 'new languages to learn' list within the next year or two, and Smalltalk will certainly be on it.
You shouldnt have to unit test for syntactical errors though, thats just crazy.
You do unit tests to prove behavior, not correct syntax. Theoretically, given equivalent functionality, you should have the same behavior based unit tests in Ruby and Java. But in Ruby, you've got to do more unit tests, because you've got to test stuff that in Java the compiler would find for you.
And if I've got to unit test every single call of every method, to make sure that the values passed in as method parameters will respond to the expected messages? Thats just insane.
And yes, I know thats somewhat of a joke example, because no one really does that. But that means that you've just lost all of that 'provable correctness' that you would otherwise have, and have to replace alot of what you got for free with a compiler, with hand-written unit tests.
So the question becomes whether other productivity benefits outweight productivity losess, and losses of provable correctness. And of course, the answer is that 'it depends'.
I've done little apps in Java, and hated it. I've done big apps in Java (couple million lines of code, 30+ developers spread across the US) and loved it. To have to work on a project like the latter without the tools you get from the IDE would be nearly impossible.
I've done little apps in Ruby, and I liked it. Havent had the opportunity (and probably never will) to do big apps in Ruby, but my gut says that it wouldnt work out very well as the project got large.
A good example is in refactorings. When you're refactoring code in a large app that is consumed by many other modules in that app, its dangerous. It's easy to cause more problems than you solve.
But the IDEs help a great deal, by showing you instantly and unambiguously where code is broken as a result of your refactoring. It does this because it can form a concrete AST.
With a dynamic language like Ruby and others, you're forced to use text-pattern-matching, which is much less reliable. And even then, what if part of your refactoring was to move a method from public to private/protected (assuming you do have private methods in Ruby, cant remember). That would be a very easy thing to miss, when you're forced to rely on text pattern matching.
With a language like Java, the IDE/compiler knows instantly. That is a big advantage.
Okay, I'm not going to give up here, because I've had so many people come back with 'but smalltalk can', yet never really explain how.
Let's try two scenarios.
1. We have a class Foo, and we have a mixed in method bar() that we only want to load conditionally.
When I'm in the smalltalk IDE, and I type Foo. does it show bar() as one of the methods? Does it show an error (or not) if I use bar() as a method of Foo.
And how is that determination made? Sometimes bar() is a valid method of Foo, sometimes its not. Which situation does the IDE assume, and how does it go about that choice?
At any given runtime execution, it either unambiguously either is or isnt a method. But until you are in a real execution of the app, with application state and configuration applied, the choice is unknown (and arguably unknowable).
But the IDE has to either show it to your or not, either mark it as an error or not. Which does it do?
2. Calling methods with parameters. Say you call a method (pass a message) on Foo, called Happy(dog), where dog needs to be able to respond to message/method 'reproduce'.
In your statically typed language, the IDE and/or compiler can tell you instantly if you've passed a value thats not compatible with the parameter.
But not in this sort of environment, because we dont know for sure until runtime, whether the value passed into Happy(dog) will respond to 'reproduce'. Given the power of runtime mixins, its arguably not possible to know whether your syntax is correct, because things change.
You say its always runtime, but thats clearly an exaggeration at minimum, and just being snarky (in your words) at worst.
Some programs are non-deterministic, in the sense that you have nearly an infinite amount of unpredictable inputs. If the IDE is going to 'run' your program all the time, in what sense is it running it? Is it making database modifications (since thats what the vast majority of software does) and reads? And more importantly, WHAT initial and ongoing state is it choosing?
Whether Ruby or Smalltalk, if you dont know for sure exactly what a variable/object is, and exactly what it cant do, then the IDE cant tell you that information, because it doesnt exist. Or rather it does exist, but it exists as a arbitrarily large set of functions, which in and of itself could be described as software.
My point in all of this (at least way back up the thread where this talk started) is that you lose so much power in a language when you take the compiler or IDE's ability to find errors away.
Not to mention the developer productivity of having to memorize or lookup every single class or method call they might ever use.
Not to mention fancy stuff like walk up the call hierarchy, do refactorings, do renames, etc. Without a proper AST, you lose your ability to do alot of very very useful things, particularly as software projects grow large.
I understand what you're saying, it just feels like such a massive step backwards in many ways, though much of Ruby is very interesting.
With that situation, even the stupidest most minor typos can be non-detectable until runtime. And even then if you are doing fancy things with method_missing, it STILL may not fail, just may do completely unexpected things.
That takes me back to the horror of 15 years or so ago when I was working with pre-'option explicit' VB. Where typos could cause completely unpredictable (and rare/intermittent) strange side effects.
That kind of thing is so hard to troubleshoot, just makes me want to tear my hair out.
I'm a little bit playing the devil's advocate here, but: It seems to me that classes should exposes contracts (ie, interfaces) that you can count on, because that creates better code in the long run. But if you have no contracts or in the case of ruby, there are contracts but you cant tell whether you've met them until runtime, that just seems like going backwards.
Well, thank you for not reading what I wrote at all.
Let me try again.
Class A is conditionally modified by adding a new method, in some execution paths.
Therefore, at runtime, there is one and only one state, so the outcome is easily determined. In some situations, it will have the new method, in some it wont. But in any one execution, it either will or it wont.
However, at design time, the state is completely non-deterministic (or at least trivially can be), since you cant predict which of the execution paths will be taken, and therefore whether the modifications are made or not.
Given that, which of the two possible future class states would the IDE/compiler show?
If you dont know the answer, its okay to say so. If its just something you've read, and you dont really know the internal mechanics of how it handles cases like this, then please just say so rather than wasting both of our times by saying 'it just does'.
Why would you ever do this in the real world?
Being able to write code like that isnt an advantage, its something that would get you fired in most good shops.
How about you come up with an example that shows off functional programming, rather than overly-concise-perl-like syntax compaction.
Just because you can put 4 things on one line doesnt mean you should.
Not sure I understand this, how are Lists and Hashes not first class objects in Java?
.... but your statements are very vague and over-arching.
They're both objects, they both implement one or more interfaces, etc. By every definition I'm aware of, they are true, first-class objects.
I'd also love something more explanatory than: 'less-broken this' and 'less-broken that'. Can you be more specific?
For example, many people decry the int vs Integer issue, is that what you're talking about?
Given that using the natives is completely optional, and you could write huge java projects without ever touching them, except where you need to optimize by using the stack, how is this that big of a problem?
How is it worse than Ruby having this ? you can put at the end of a method, but it doesnt really mean anything and not enforced in the runtime. So its an equally optional thing, but its use is pure sugar, and its not actually seen or heard by the runtime at all.
I'm not saying that there arent aspects of ruby that are superior
Mock object code in Java unit testing can be HUGE number of lines.
It's very doable as long as you're using interfaces (everybody was using interfaces, werent they?) so you just write a skeletal mock that implements the interface and so a special wireup in Spring to inject that mock.
But that is complicated and hideously verbose.
So I appreciate your post
Mind you though, in Java there are some great mock & unit testing frameworks that make this problem much less of a problem. In most languages this is hard or impossible, because it means reaching inside the execution of A and temporarily changing the functionality of B. This part of it is easy (if verbose) in Java. You just write a mock class, and have Spring inject it instead of the regular implementation when running that test. Since both the real and the mock implement the same interface, and you've coded to an interface, this works quite well, though its anything but trivial. Thats a very very common approach.
Hard to imagine Java without Spring though
I've heard that said before, but I'm not informed enough about Smalltalk to agree or not.
Explain to me though how thats possible, given:
You can modify classes/methods at runtime.
You can conditionally do so, so in some execution paths the modifications exist, and in some they dont.
Given that, how does the Smalltalk IDE/compiler determine whether the new/modified method is there during design-time, given that its a conditional runtime modification?
A perfect example of this is in Rails & ActiveRecord. Lets say I have a class backed by a table that has 50 fields in it.
Why the hell cant the language/environment just let me pick from a list, instead of forcing me to memorize all 50 elements, or keep all table definitions open in front of me. Further, if I typo one, why the hell cant I tell until runtime.
Thats just an absurd step backwards in developer productivity (talking about Ruby here, I'm just not up to speed enough on Smalltalk to say whether it works similarly or not).
1. Use encapsulation, rather than Inheritence.
2. Use Spring to put logging pointcuts either before or after.
However, thats not really my point
The language features (mixins) that you're showing here with Ruby are a double-edged sword.
They make certain things like you demonstrate very easy, but they come at a HUGE cost.
It basically makes it impossible to find whole (huge) classes of errors at design/compile time. To make things worse, you could have a conditional mixin. The result is that its IMPOSSIBLE for the IDE or compiler or static analysis tool to know whether a method exists, or I've passed the right number/type of parameters in.
Not having a fixed and knowable/provable syntax tree makes so many useful things impossible.
That sort of thing should be caught instantly, and you shouldnt have to wait for runtime errors or unit-testing failures to show up. And you shouldnt have to write unit tests to confirm syntactical correctness.
This sort of thing takes me back to the bad old days of VB w/ Variants and untyped/undeclared variables.
Frankly, I'd LOVE to have the Ruby syntactical sugar, closures, and expressiveness in a statically typed flavor of it with interfaces. I miss my interfaces when playing with Ruby. Design by contract is such a useful thing, its terrible when you miss it.
Your plan was precisely the same as my plan, except you wanted to move her to a new OS for no real benefit. In both cases he's non-admin and cant install things, which solves the primary problem as stated.
What MS should have done would be to do the 'Vista Capable' thing accurately. Then for the folks who want a $300-400 computer, they would buy an XP box. And they would see the Vista boxes right next to them, costing a couple hundred more, but faster hardware and (as perceived) more features. That would be an effective differential pricing plan.
Based on some things I've seen and read, at this point I'm really starting to blame the OEMs.
Alot of them are just absolutely killing the machines with crapware and ancient (ie, bad) drivers. Here's an excellent article on the topic.
A clean build of Vista on a machine with well-supported drivers is fast and stable, in my experience. But I'm not the normal user.
As I've said a few other places here today
The technology improvements MS made in Vista are quite impressive. And Vista 'should' be quite good, much like Server 2008 is quite good.
But its all been in the distribution, marketing and ecosystem development.
They crumpled and ruined the consumer experience with the 'Vista Capable' marketing campaign. Thats going to turn out to be one of the biggest nails in the Vista 'perceived-success' coffin.
They didnt force the OEMs to only sell Vista machines that performed well.
And they did a TERRIBLE job with driver manufacturers, particularly Nvidia and ATI. If you look at what causes the most bsod/bugchecks in Vista, its those two.
Mind you, of the file systems I'm aware of, ZFS is the only one that handles this well. Dont even get me started on ext2 or ext3. Maybe Novell's systems were better, that wouldnt surprise me. Novell's directory systems were way ahead of their time. It's unfortunate that they didnt have the business acumen to survive. NetWare volumes never needed to be defragmented, ever. To be fair, neither does NTFS except in extreme situations. I dont think, in 10+ years of doing this, that I've ever defrag'd a server filesystem. And I've never defrag'd one of my desktops.
Under typical circumstances, NTFS doesnt need defragmentation. A certain level of fragmentation is normal and desired. Where you run into problems with NTFS is when you get very full drives and within a few percentage points of 100% full. Other than that, it just doesnt come up.
It's basically a big placebo that the ignorant use. It doesnt actually help performance any under normal circumstances, but it makes people feel like they're doing something. And don't even get me started about what happens to AD once you start to scale it up... it's embarassing how poorly it performs by comparison to even NDS - and against eDirectory it's just sad. The NetWare 5.0 servers that we are slowly migrating away from after nearly 10 years of constant availability, running dual-Pentium III processors, consistently outperform the Windows 2003 servers running on modern hardware with a LOT more memory and MUCH faster hard drives for things such as replication and file system access/rights validation and we're not even halfway done. So dont move. Stay on NDS. No one is holding a gun to your head and forcing you to move to Windows and AD. Sun even has a nice directory product, and there are open source ones as well. Why arent you using any of those?
I've got to say, if you're going to sit around and bitch about the MS solutions, but then go ahead and implement them anyway, then you're not going to get much respect for your opinions. Your actions are different than your words. Maybe you're just not a decision maker wherever you work. What are the senior technical folks doing, and why are they pushing this?
Someone must have a reason to be doing so. Novell eDirectory looks compelling on paper, but hardly anyone runs it, and Novell isnt exactly the most focused company in getting their products out there.
Agreed that its still intact, why wouldnt it be? I guess what I should have asked before is why it requires massive changes to be 'good'?
Some of the things that I see include new process scheduler, new IO scheduler, new network stack, new memory manager, major improvements for SATA with a generic driver, new bootloader, new heap structure and manager (improved fragmentation performance), and settable IO priorities (ie, ionice equiv).
These are pretty significant and low level.
I dont think its reasonable to expect a commercial kernel like windows nt to change as much as something like linux. The linux kernel folks break everyone badly alot (ie, driver writers, 3rd party authors, file system authors, system software authors) with significant changes to kernel APIS, behavior, and ABIS.
This sort of thing doesnt really work in the commercial world, as people come to rely on even undocumented kernel structures. It's not right that they do so, but if they change stuff very often, 3rd party software breaks. And the consumer/end-user only knows that it broke when they did a MS update, so it must be MS fault, even if it was completely the 3rd party's fault.
Hell, half the anti-virus companies made a big publicity stunt when MS tried to lock down certain kernel data structures from direct manipulation (ie, not through the APIs). Even though its a TERRIBLE thing to do so, MS gets beaten down in the public eye because people just dont understand this stuff.
Anyway, you're right in that it will never move as fast or as interesting as Linux kernel, but thats okay, there's place in the market for a more conservative stable kernel. But just because its isnt majorly rehauled every year, doesnt make it bad.
I'm confused about your complaint of the NT kernel. Its widely agreed to be fairly decent. Nearly all of people's complaints are in win32 or userland stuff (explorer.exe, iexplore.exe).
In addition, there were some very nice core/kernel improvements to windows in Vista. You can read about them here.
It doesnt take much research to see where MS went wrong with Vista, and very little of it had to do with technology.
As an example, go use Server 2008, which is the same core system as Vista SP1 (sans the userspace stuff). It's what Vista should have been for most folks.
That being said
It almost always just automatically detects it, and 'just works'.
The worst I've ever had happen is when switching between different environments, every once in a while, it wont pick the right profile (ie, docked to the docking station, external monitor) and I have to spend 60 seconds setting it up.
Even when it doesnt automatically set it up, configuring multi-mon on windows is the easiest thing in the world. Just line up the little boxes how you want them, set which one you want as primary, and you're done.
Really? Where have you heard this?
.net is making huge interesting leaps and bounds, with the DLR, adding functional aspects into the language, etc.
Technically,
It's doing alot of things that are way ahead of Java.
It's used hugely in corporate dev shops.
Frankly, I've heard alot more talk of 'java is dead' than I have of '.net is dead'.
I doubt if they would EVER productize it for the desktop. What would be the point of a desktop OS with no GUI no sound and only a command line interface? By spring 2010 they should be selling quad core 4GHz machines with 4GB ram standard. That should allow users to run the Vista kernel at a reasonable speed and even leave some of the eye candy turned on. What nonsense.
I've got a (nice) HP Compaq 8710w laptop. C2D 2.4, 4GB of ram, and Nvidia Quadra 1600M w/ 512mb of ram built in.
Yes its top end when I bought it (most of a year ago).
But you know what, it runs Vista Business x64 nearly flawlessly. Other than when booting (which I almost never have to do) it never hits the hard drive. It's responses are nearly instant everywhere. It's quite nice. And thats with search/indexing and system restore and shadow copy all turned on.
I think what you'll find is that Vista will run quite fine on lesser hardware, as long as there isnt a bunch of crapware installed from the OEM, and the drivers are quality.
WinFS was always a layer on top of NTFS. It never was intended to be a general purpose file system.
WinFS was not designed around the MinWin kernel. The MinWin kernel didnt exist in any form until well into the Server 2008 development cycle, which follows WinFS dev by like 8 years.
The Win2003 kernel was NOT used in Vista. Yes, thats where they started way back when, but Vista is a major-ver change over the 2003 kernel.
The Server 2008 kernel is not an updated win2003 kernel. It's an updated Vista kernel. In fact Vista SP1 and Server 2008 are largely the same product, with the differences being in userland stuff. It is really unfortunate because the NTFS is horribly outdated and lacks many modern features that help find files. From a user perspective, being able to tag files with search-able information is invaluable, and is the main reason I only store my photos and non-Word documents on Linux and Mac. Actually NTFS has had arbitrary metadata built into it for more than 10 years. That feature is positively ancient. For whatever reason, MS has never chosen to productize it and write userspace apps to manage that metadata.
So interestingly, you could have done that keyword tagging and indexing on those a LONG time ago, but MS chose not to productize that stuff for whatever reason.