Out of curiosity, i tried a few tutorials on code.org.
I began with this one.
Have you seen this graphical syntax using blocks ?
Is it some kind of standard ?
Or is completely home made ?
Here is what it looks like :
http://files.websitetoolbox.com/149581/1788549
Where can i learn more about it ?
I think it is really easy to read, and i wonder if i could use somewhere else, programming c# or c++, java, even javascript.
I am still not sure if business code would really be easy to read using this syntax.
It's likely to be some form of OpenBlocks, it's a way of representing your code and what it does in a more intuitive fashion, you can read more about it at the link I posted as a comment.
Notably, a similar solution was in use for creating Android apps too .
This is called blockly. You can find a lot of information from blockly's FAQ. Hope that helps.
Related
I am working through the Sassdash Library, and there are numerous functions that use a argument $this-arg. I am having a lot of trouble understanding what it does. Can anyone simply explain what this does and what some simple use cases might be?
It is similar to how this works in JS.
I have been C/C++/VBNET programmer for a long time. Now Ruby advanced concept is attracting me. So I decided to learn how to use it.But the "Behavior" of Ruby used to confused me. I usually feel like can't completely control my Ruby program.
Can you help me get clearly about this ?
(Maybe some of your favorite guide about "Ideas" and "Styles" in Ruby may help >:D< . Thank)
Ruby is quite an unusual programming language if you are more used to static/declarative style languages like C/C++.
I suspect it's the highly dynamic nature of the language which is causing you a problem, it can be difficult to get your head around this when you encounter it for the first time after having used only the more static languages. Ideas like Duck Typing can seem weird if you are used to declaring variables as strict types before use.
I would thoroughly recommend working your way through one of the excellent books about ruby that are out there. Don't just mess around writing code without really understanding the concepts.
Personally I really liked "The Ruby Programming Language" from O'Reilly, but I have experiance of a lot of different languages so I'm used to some of the more dynamic features in Ruby.
However you may prefer to start with something less terse such as Dave Thomas' "Programming Ruby" (make sure you get the 1.9 version).
Work through one of these books, do the examples, play around with the code. That way you will get a thorough understanding of the language.
Best of luck. Once you get your head around it, Ruby can be a very powerful language.
I think that the book Design Patterns in Ruby might help you. The first chapter describes the syntax of Ruby (which I guess that you won't need), but the rest of the book goes through the classic design patterns and shows you a Ruby way of approaching them. It's very clearly written and I learned a lot about Ruby idioms from it.
If you can talk to a Rubyist then that will probably help a lot - from experience, a code review or pairing session with someone else can get you over mental blocks better than anything else. If you don't know anyone, try writing some code then post a link to it to the Ruby Talk mailing list with questions. This is a very friendly community, and people are happy to help.
I recommend reading Why's Poignant Guide to Ruby. It will open your mind to the wonders of working in a dynamic language. Or it will piss you off with its cartoons of talking foxes. Either way it will change your thinking about Ruby :)
There are many LINQ implementations such as LINQ-to-Flickr. To make something like this, do I make my own custom LINQ provider?
Thanks
Have a look at this tutorial
Aha. That's the only way.
Hit in google 'write LINQ provider'. There are many tutorials out there.
Start with understanding what exactly Expression is, how it differs from lambdas and how to work with them.
I find this book quite helpful too (at least - beginning).
Yes, to get started, the best place is looking at the IQToolkit on Codeplex. You'll learn a lot about how it works.
If you do find you need to build your own then look at IQToolKit and the The Wayward Weblog for a full series on how to do it.
Which language ( that is not oop ) should I consider using for writing gui windows apps ?
I guess the obvious answers are visual basic and C , but am wondering if I should look into anything else
am not saying OOP sucks or anything. I just don't.. not using it. The END
ty
Edit: I just want a language that has a non oop paradigm option and that is/can be used to write a windows gui application .
It is quite possible to write procedural code in any language.
There is FreeBasic
I'd personally recommend giving Fortran a go, it's quite nice...
I'd use Python. Sure it can be used in a OO way (as pretty much all other languages can as well), but it's pretty easy to write clean, simple, procedural code with it as well.
C would be my choice, Visual Studio supports it and has an excellent debugger. There are also plenty of examples out on the web in C for Windows programming so you'll have the easiest time getting your code to work.
OO is kind of a pervasive paradigm these days. It's pretty much impossible to avoid, even languages like VB and C can be used to program in an OO way, although I do get what you mean. Have you considered Fortran? COBOL? J? Perl? Python? They can all pretty much be used in a non OO way.
Not to mention assembly language.
F# I guess, avoiding its inherent object-oriented programming model. But do you like functional languages and the .NET framework?!
Out of curiosity, why do you need such a thing?
Windows programming is OO by design. Even if you use C, all the API functions work like OO.
Every handle has a corresponding Create function
CloseHandle if used to close any object, not just a specific type
And finally every single API function gets a Handle to a relevant object, just like the old implementation of OO in pure C with structs - the equivalent of this.
Well, there are guys who are still using Visual Foxpro, or Visual Basic 6 (which is NOT OO, contrary to what some people say).
C and Windows API. It is not OO, but feels like, because OO (C++, Java, C#) is nothing but making structs into objects.
Hai guys,
I ve seen people including comments in their program..
Is it to improve inter-programmer communication
and code readability, by explicitly specifying programmers’
intentions and assumptions?
Should comments be in technical terms rather than in natural launguage terms?
How to use comments as effective as possible?
Is it really a good practice adding comments to a program?
Comments should only be used to explain why the code is the way it is. It should never explain what the code is doing. What the code is doing is described by the code.
That being said, some languages have tools that look for special characters in the comments in order to generate documentation. Java is one such language. But these aren't so much code comments as they are documentation that happens to use the same syntax as language comments.
Comments can be used for auto-documentation, communication amongst other developers, memory, todo lists, or basic explanations of functionality. Note that comments ought to be supplementary - if your code needs comments, you need to reconsider your code.
To be as effective as possible, work out a template for your comments to exist in. Again, this will not only help you read and understand your code, but it may help a parser create documentation for you from your comments if they're in a consistent format throughout the code.
Writing clear code is always the first step to making your code easy to understand. You can then explain parts that are not clear by looking at the code, in comments.
For myself, comments explain what I was thinking at the time. That way, six months from now when I don't remember what I was writing, I can use the comments to understand.
Some classic uses of comments:
Explaining why code wasn't done in the most obvious way -- Such as interfacing with systems that use weird or old ways to talk.
Explaining what code might call this code -- Such as in large and complicated system. You can add examples showing code that might need to call this.
Documenting exceptions to current coding practice -- Such as legacy code that hasn't been refactored to use the current systems.
As a rule, if you ever find yourself doing something non-obvious, comment it.
An alternative way of commenting is to start by writing the body of a function as comments. Then break the comments apart and put the code underneath. When it finally works, cleanup and fix the comments.
Ciao!
I try and comment each function describing at a high level, but precise way, what the function does. The precision should be such that it is not necessary to read the body of the function to understand what the function does, or to re-implement it and have it work perfectly with any code that calls it.
Other than that, I try and keep functions small enough that the above is basically all the necessary documentation.
Once in a while, there may be something obscure or odd in what is being done in the code - I document that. Anything that isn't obvious or intuitively right, or that you spent some time thinking about, should be documented.
Just imagine you have a memory problem and will forget writing this program in a month. Then imagine you have to go back and fix it. What would you like commented and how could those comments be made most useful to you?
it's better to make the program self-describing, then no much comments are needed.
First try to write code so people can follow without comments.