Slashdot Mirror

All of the Speech Recognition software that you commonly use is geared toward conversational language. You could create one that follows the language and grammar of code, but it would require different training. Consider the search suggestions you get when you type in the search bar.....that's how Speech Recognition works. Based on the previous words, it creates a list of likely next words and then determines which one matches the spoken words. When I type "void" into Google, it suggests to me the following:
void
void(0)
void movie
void definition

None of those suggestions are "void function". And Google Suggestions aren't trained for more normal language like Speech Recognition would be because people are less likely to search using full sentences.

What you are attempting to do is technologically possible, but you'd need to use the Speech API and create your own trainings (try this article and focus on the Grammer Building: http://www.c-sharpcorner.com/u...).

Regardless, if you are using that particular Speed API, I don't think you are using the one in the article. I think the one the article is measuring is the one that would be found in Azure (https://azure.microsoft.com/en-us/services/cognitive-services/speech/).

I found this..seems you can make one for about $40 http://www.c-sharpcorner.com/uploadfile/mgold/virtualoscilloscope08292005103442am/virtualoscilloscope.aspx

http://www.c-sharpcorner.com/UploadFile/mgold/ZenGUIProgramming03122008231252PM/Images/BadGuiDesign.jpg

Sure C# has pointers, but it might need to be run in the unsafe environment:
http://www.c-sharpcorner.com/UploadFile/rajeshvs/PointersInCSharp11112005051624AM/PointersInCSharp.aspx

Behind the scenes it has to have pointers, of course.

No, it does use a mark-sweep garbage collector. This does present challenges to real-time applications; I imagine the GC is tunable to some extent (I know the Java one is)...

Furthermore, for anyone wanting to know the differences between .NET and Java or wanting some information on how the CLR (.NET VM) works, I found this comparison to be very helpful.

C++ is the only remaining major language which has hiding without safety. C has neither. Java, C#, the Pascal/Modula/Ada/Eiffel family, and all the scripting languages have both hiding and safety. That lack of safety is responsible for most of the crashes and exploits in today's software. When a virus takes over your machine due to a buffer overflow, it's probably because of that bad design decision in C++. Every day, hundreds of millions of people must suffer because of that mistake.

The largest single problem comes from the decision in C to treat a pointer and an array as the same thing. This seemed convenient thirty years ago, but created a language in which the size of an array is not permanently associated with the array. In particular, the fact that arrays are passed to functions without size information is a huge source of trouble. This, of course, is why we have buffer overflows.

Attempts were made in the STL to fix this problem, but it didn't really work out. Trying to retrofit strings to the language via the template mechanism was not all that successful, since so many libraries and system calls required the old-style strings.

Safety is not a performance issue. It's possible to do checking very efficiently, if the compiler knows what to check. Subscript checks can usually be hoisted out of inner loops at compile time. But this is not possible for C++, because the subscript checking, when enabled, is in the STL, not the language.

The second big problem in C++ is the need to obsess on "who owns what". Memory allocation is the nightmare of C++. Again, the STL tried to address this, and again, it was botched. The auto_ptr debacle illustrates the limitations of the language. There have been many, many attempts to implement "smart pointers", and they're all unsafe. At some point, you have to extract a C-type pointer to get something done, which introduces a hole in reference counting. If you don't extract raw pointers, you spend too much time updating reference counts. Again, this is something that a compiler could optimize if the compiler knew more about what was going on. But with reference counting implemented at the macro level of templates, that's not possible.

Garbage collection is occasionally proposed as a panacea, but it's not compatible with the concept of destructors. In a garbage collected language, what destructors and finalizers do must be severely limited. This is contrary to the C++ concept of "resource allocation as initialization". You don't want to close a window from the garbage collector. Also, introducing garbage collection introduces a form of concurrency, in a language that doesn't handle concurrency well. There are workarounds for this, but like most workarounds, they're painful. Take a good look at how Microsoft's "Managed C++" approached the problem. It's wierd; read about "resurrection, where an object comes back to life during garbage collection.

Those are the two elephants in the living room of C++. Denying them will not make them go away. This is harsh. But it's not wrong.

Of course, wikipedia's article says it isn't a file system, because it uses NTFS underneath, or is at least based on NTFS. Even so, most sources can agree that the best definition is WinFS is a file system with some added features.

Anyway, I don't think the comparison is so bad. Spotlight, WinFS and Reiser4 may not technically work the same, but they all have the goal of presenting the user with a database interface and allowing the user to query that interface, much like a desktop search, only built into the OS itself. It is this level, the interface level, at which comparison is apporpriate. Not at the implementation level, as you already mentioned.

The main difference is that these tools only search on filename etc. that are available with flat file systems. With WinFS you can search not only by file name but by the files properties (i.e. All Photos that "Jim" is in). It also indexes and stores items in relation to other items and acts just like a database exclusively for files. For more info on the WinFS data modle check out http://www.c-sharpcorner.com/Longhorn/WinFS/WinFSD ataModel.asp

People still using COBOL can migrate to COBOL.net. Fujitsu implemented a this abmonination.

WinFS, at least conceptually, is a totally different animal. Rather than files being opaque, linear sequences of bytes, files are composed of schematized data, much like XML documents and their XSD schemas. So much like XML documents in large part obviate the need for application developers to create their own binary formats (and the necessary binary parsers and writers), Windows developers can write to these higher-level APIs.

Furthermore, WinFS allows the operating system to have much greater access to the semantics of the data, and as such, it can provide more services to the developer. For example, WinFS schema allows you to express DAG relationships between entities, doing ref counting and cleanup when an entity is no longer referenced. Also, you can get event notifications not just at the file level, but on sub-file-level entities. The WinFS team was even going to provide sub-file-level replication "for free", but I believe this may have been shelved for now.

And they have also put a fair deal of work into letting all this work alongside the "legacy" datastream model.

From a full-text-search perspective, probably the biggest difference vs. Spotlight and Google Desktop is that any native WinFS-based app should not need to write a plugin. The relevant plaintext and metadata would simply be transparent to the filesystem.

Of course, at the moment WinFS is far from shipping while Google Desktop is out and Spotlight seems imminent. Still, WinFS is as ambitious as anything I've heard of Microsoft doing, and as far as I know they're not following in anyone's footsteps this time.

Here is a decent high-level summary of some of the features of WinFS. You can also go to MSDN and check out the preliminary API's (I believe they're all under the System.Storage namespace).

Microsoft has not released the .NET framework on any platform but Widnows, and doesn't have any plans (that they're talking about) to do so.

That's assuming you don't count Rotor, Microsoft's reference implementation of the ECMA-standardize bits of .NET (the C# language, the CLR, etc, but not bits like WinForms), which at least works on various BSD platforms, and is licensed such that you can safely port it to other platforms, or use it as the basis for a reimplimentation (think BSD's network stack, for instance).

the only real worry for Mono is that Microsoft would change .NET enough to break what compatibility they have, but the Mono project has already explained why this doesn't worry them.

Also keep in mind that Microsoft has a 10 year support plan for each new version of the .NET framework. Tha means that 1.0 will be supported for another 7-8 years, 1.1. will be supported for another 9, and 2.0 will be supported for 10 years from release (which should be sometime next year?). That means that even if Microsoft does make breaking changes in a new version of the platform, you can still build applications against older versions that Mono does support. As well, each framework has some amount of backwards- and forwards-compatibility (for instance, it's possible to run 1.1-targeted .NET apps on the 1.0 framework, with a few exceptions). Microsoft generally does a good job of listing backwards and forwards breaking changes between versions of the framework. (Yes, GotDotNet.com is a Microsoft property.)

You can. Fujitsu implemented a COBOL.NET. It's an abmonination.

Isn't all information potential file data? Is Microsoft really doing something different than has been done before?

The article also states "WinFS uses a direct acyclic graph of items (DAG)."

The math goes back to the 1970's, as referenced by MathWorld Old math can be used in new ways. Is his a new way when it's used in the FS that Microsoft is attempting?

The articles also says: " the WinFS data model provides the following concepts to describe data structures and organizations: * Types and subtypes. * Properties and fields. * Relationships. * Constraints. * Extensibility. "

Does the new Reiser4 file system support any of these concepts? -- Is WinFS really as new and exciting as the marketing and media says it is?

Thanks.

The goal is to make their hard disk search easier, handling all types of data. Another goal is to be like open source, by giving proprietary software more reason not to re-invent the wheel, because they can access the data through another application. They will use meta data to define everything so any application can use any data.

The problem is that 3rd parties all have to agree on a standard, and no doubt patents will be involved, licensing, preventing applications from working well with one another to gain an edge, viruses will have a MUCH easier time doing silly things with your data (this could make distributed data mining a reality if a worm spreads enough), who knows if it will work in practice as well as it should in theory.

This is why WinFS doesn't replace NTFS but cooperates with it, it's a layer of meta data. Needless to say MS have a huge task on their hands.

Another great tool for stress testing your site is Jakarta JMeter. Gives you a nice GUI for watching your response times plummet as your site is pummeled.

From the article:
Siege now supports a new proxy tool called Sproxy, which harvests URLs for testing. The premise behind Sproxy doesn't make much sense to me... Personally, I prefer Scout for getting my URLs, since it just goes through a site's links and adds them that way.

The advantage of using a browser to set up your test plan is that it better simulates real traffic patterns on your site. Microsoft's Application Test Center does this, and JMeter has a proxy server similar to Sproxy.

When you're trying to replicate problems with a live site, however, it would seem more appropriate to me if you could base your test on real traffic to the site. I wrote a load testing tool once that used web logs to simulate the actual traffic patterns, but it was incomplete, mostly because web logs don't record POST data. A good stress tool could come with an Apache/IIS/Tomcat plugin that recorded traffic for use in stress testing.

COBOL is a supported language in the .NET framework.

COBOL.NET and code & tutorials.

That's Sun's opinion, but disregard for operator-overloading is by no means universal.

Only dumb programmers become any more confused by operator overloading than by other kinds of overloaded functions.

I don't want to reduce the effectiveness of the smart ones by sheparding the stupid.

Or you can use SharpDevelop, specifically written to use the free compiler in the .NET framework SDK.

Unfortunately, it doesn't have a GUI editor to work with WinForms yet. This attempt is the best I've seen.

There May Be Trouble Ahead
by Alan Williamson

As Nat King Cole famously sang, we have to "face the music and dance..." This month's editorial is coming to you with a reader beware warning!

I've been engaged in some great debates over the last month on a variety of topics, but the one that has caught my interest is the old chestnut regarding the longevity of Java. Is it here to stay? If not, how long do we have? Quite rightly, it's being talked about and I've had the good fortune to brush shoulders with a number of big names in our industry who have given me their perspectives on the whole debate. I have my own feelings about where Java is headed and I do believe that if, as a community, we don't get our act together, we may have only five years left at the most. After talking to my counterparts, it would appear I'm being overly generous with five years.

What's happening? Well, it's our old friend C# and its relentless march toward the development community. Setting aside the old argument that due to Microsoft's dominance it may well win the day, it's interesting to look at other reasons why C# may win the battle. Let's blow away some misconceptions that you may or may not be aware of regarding this new kid.

Myth #1: C# is a Windows-only technology.
You could be excused for believing that, but did you know there's a major movement in the open source world to port the CLR (Common Language Runtime, i.e., their JVM!) to operating systems other than MS Windows? Linux, to name one. Imagine for a moment being able to run your .NET services alongside Apache on a Redhat box, seamlessly integrating into the rest of the network. This alone would be a major blow to server-side Java. It's also a subtle way for Microsoft to unofficially support the growing number of Linux seats without losing face (read www.halcyonsoft.com/news/iNET_PR.asp).

Myth #2: C# is an inferior Java clone.
This is the most dangerous one and the one you probably tell yourself in order to keep the scales tipped in Java's favor. The truth is, it's not an inferior clone; it's a different clone, with many arguing that the differences are minute to the majority of the developer community. It will be frighteningly easy for Java developers to move over to C# with no real headaches to contend with. I suspect this was always on Microsoft's mind when developing the language (read www.prism.gatech.edu/~gte855q/CsharpVsJava.html).

Myth #3: C# is for developing Web services only.
Most definitely not, and I have heard this one retorted back to me on a number of occasions. Ironically, this is the one area that could really hurt Java Ð on the client. As you know, Java has not made any significant headway in this space due mainly to its awfully slow Swing implementation. While the recent release of JDK1.4 has brought significant performance gains, it's still nowhere near the speed of its native Windows applications with respect to fast, snappy responses (although it must be said, the speed of a Swing application on a Mac OS-X does show what could be achieved). C# is the new building block for Windows applications, the next VB! And we know how many applications popped up when VB hit the market (read www.c-sharpcorner.com/WinForms.asp).

Okay, how many of you think I've abandoned all hope for Java and have gone to the dark side? I suspect some of you are questioning my loyalties at this precise moment, wondering if I'm fit to occupy my role as EIC. Well, don't panic, I'm merely being a realist and looking at it from all angles. You'd be the first ones to complain if I buried my head in the sand and just ignored the threat. We have to look at this together and come up with a strategy that will enable us to effectively take on C#. We'll be getting a lot of heat from all over and we need to be armed with the information and prepared to go back to the drawing board and reeducate the masses. Sadly, they are being led a merry dance by Pied Piper Gates.

Allow me to cite you an example of such blind ignorance and if this doesn't scare you, then I don't know what will. I was recently involved with the Scottish government, discussing technology and what have you, where naturally the topic of Microsoft was high on the agenda. Excusing the fact that these people took a certain pride in believing they knew what was going on and loved name-dropping, the phrase that caught me off guard was the following: "Java? No one is doing that now. Microsoft is no longer supporting it."

Wow! Talk about a major miscommunication. And this from someone who controls budgets for the technology sector in Scotland. Ironically, I believe he really thinks he has his finger on the pulse of technology. It's sheer ignorance like this that scares me the most. Microsoft has successfully planted and nurtured the seed in people's heads that just because it isn't supporting Java in Windows XP, Java is dead. I have to admit I was taken aback and quite flabbergasted when I heard that retort. I really didn't know where to go with that. So much background information was obviously missing that I wasn't too sure if I would come over as patronizing and whether, ultimately, they would understand.

Sadly, this is not an isolated incident. Ever since I started writing about this topic in my editorials, I've been hearing stories from you regarding similar misconceptions and it scares me. We have a beautiful language here in Java; it has achieved industry-wide support and is pushing forward with great velocity. What can we do to support it?

You do realize we need an anthem. All great causes have an anthem. Something for us to get behind and sing!!! Suggestions gratefully received. We need a Java song!

Until next month...

Author Bio
Alan Williamson is editor-in-chief of Java Developer's Journal. During the day he holds the post of chief technical officer at n-ary (consulting) Ltd, one of the first companies in the UK to specialize in Java at the server side. Rumor has it he welcomes all suggestions and comments.