Related
Just wondering if when creating a login/registration web page using scala is very similar when doing with PHP/HTML which I have used in the past. I've just decided to start learning scala and am a total beginner with no clue. With PHP/HTML, I would use a form, 'POST' method and then the appropriate my_sqli prepared statement insertion and selections. Is it similar or very different in terms of overall methods and way about going with it (obviously excluding the minor differences in syntax). How and in what ways is it different or similar? thnx
Scala is totally different from PHP. Finding connections between them is really hard. I would say that Scala is better in every way but bashing PHP is just too easy nowadays.
I would suggest you to give a look at Scalatra, arguably the most mature among simple web frameworks in Scala. Every framework works differently but you can get an idea of how you think and write code in Scala giving a look at Scalatra examples.
Also, if you never worked on a JVM, it will take a while before being able to properly develop logic in your code. There are many things to learn about the environment (and obviously about the language too) before being able to develop a web app. My suggestion is to first spend some time studying the language and only then begin approaching web development. If you need a language that you can pick up and start writing code, Scala is not the right choice.
There are several packages out there that help in automating the task of writing bindings between C\C++ and other languages.
In my case, I'd like to bind Python, some options for such packages are: SWIG, Boost.Python and Robin.
It seems that the straight forward process is to use these packages to create C\C++ linkable libraries (with mostly static functions) and have the higher language be extended using them.
However, my situation is that I already have a developed working system in C++ therefore plan to embed Python into it so that future development will be in Python.
It's not clear to me how, and if at all possible, to use these packages in helping to extend embedded Python in such a way that the Python code would be able to interact with the various Singleton instances already running in the system, and instantiate C++ classes and interact with them.
What I'm looking for is an insight regarding the design best fitted for this situation.
Boost.python lets you do a lot of those things right out of the box, especially if you use smart pointers. You can even inherit from C++ classes in Python, then pass instances of those back to your C++ code and have everything still work. My favorite resource on how to do various stuff is this (especially check out the "How To" section): http://wiki.python.org/moin/boost.python/ .
Boost.python is especially good if you're using smart pointers or intrusive pointers, as those translate transparently into PyObject reference counting. Also, it's very good at making factory functions look like Python constructors, which makes for very clean Python APIs.
If you're not using smart pointers, it's still possible to do all the things you want, but you have to mess with various return and lifetime policies, which can give you a headache.
To make it short: There is the modern alternative pybind11.
Long version: I also had to embed python. The C++ Python interface is small so I decided to use the C Api. That turned out to be a nightmare. Exposing classes lets you write tons of complicated boilerplate code. Boost::Python greatly avoids this by using readable interface definitions. However I found that boost lacks a sophisticated documentation and dor some things you still have to call the Python api. Further their build system seems to give people troubles. I cant tell since i use packages provided by the system. Finally I tried the boost python fork pybind11 and have to say that it is really convenient and fixes some shortcomings of boost like the necessity of the use of the Python Api, ability to use lambdas, the lack of an easy comprehensible documentation and automatic exception translation. Further it is header only and does not pull the huge boost dependency on deployment, so I can definitively recommend it.
I am creating a new domain specific language. How do you test a language, or something you can do (transform, compile, check) with a language.
What are good references or starting points for learning about best practices?
You can build programming languages the test-first way:
Create a script in the language you are creating
Assert that the script works by investigating its side effects. You can do this by e.g. creating unit tests in the host language (the machine language) that execute the script in the new language.
If you want to learn more about how to create programming languages, "The Definitive ANTLR Reference" book is a good starting point.
A very helpful pattern to test the syntax of a new language is the following:
Interpret a script and build an AST
Generate code in the new language from the AST
Generate an AST from the generated code
Assert that both AST structures are identical
Sometimes it's more convenient to assert that generated code from two ASTs are identical.
Build your tests like you build your language:
lexical
syntactic
semantic
I like to hijack working unit tests from other projects. For example, if I know the boost unit tests are working, then I can just re-run the test after XYZ new compile-time operations and make sure they still pass. I'm not sure what's available for other languages, but IMO for C++, boost is the definitive compiler stress test.
For a new language, I'd subject it to my standard evaluation procedure:
Solve the Project Euler problems in the new language.
Build a unit test suite that runs down the solutions you wrote for those problems and make sure the compiled code still returns the correct answers.
It's far from perfect, but it will force you to build a wide range of algorithms/strategies, and the result is a compact validation test. If you make a change in the language specification, it wouldn't be hard to update your solutions to accomodate them.
This might be completely unrelated to what you were trying to ask, but PHP comes with automated test scripts, so that anyone can test that basic language functionality (variables, 'if' statements, loops, etc) are working correctly.
The traditional way is to bootstrap your implementation in the language you're implementing. That way you get a large test suite for "free" (relatively, of course), and you have a strong incentive to fix problems and optimize.
The first thing to research is unit testing because this is something that developers should do right from the beginning. In fact some people even advocate writing unit tests before you write any actual code.
There are lots of unit testing frameworks around for most popular languages like Java, Python and so on. This blog post gives a comprehensive list of the unit testing frameworks for Javascript.
Next step is to learn about lint programs which examine a codebase for incorrect or unclear constructions. This is often not included in a build process, but is a valuable part of testing. There are lint programs for C, Javascript and Python among others.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
the question im asking, is it worth to learn a new language like groovy? cause if i learn groovy, it feels like i code in groovy and not java. and how smart is that when i have to be good in java to code desktop applications too in the future. so if i use groovy a lot for web applications, i will just be worse and have to start over to be good in java when i code desktop applications right?
so why don´t I just stick with java and be good at ONE language instead of having to switch between 2 languages and their syntax. Cause it would be so confusing...
Groovy is a nice, scriptable and easier-to-use Java "knockoff" – and I don't mean that derogatively. while Java is a language to be compiled, deployed and (often) run on Enterprise servers where performance matters, Groovy is a language where you can quickly create a program to get something done. Often that something is fairly simple, so it's an hour's or a day's coding effort. Often the code is only run once and then thrown away. Because Java has more boilerplate and formalism in it, you can do this kind of program more quickly and hence more efficiently in Groovy.
However, just to give you some perspective, Groovy is a relative newcomer stomping on the turf of various other, better established scripting languages:
Perl is one of the grandfathers of scripting languages; rarely does a Unix server get installed without Perl on it, and Perl scripts are the lifeblood of many servers. However, Perl is a write-only language that looks like line noise to the uninitiated. There's more than one way to do everything, so styles diverge drastically. Perl coding tends to be a bit messy.
Python is a fresher, cleaner script language than Perl, and is these days preferred by many as a scripting language. It's fun to program in, it gets things done and because it's been around for a few years, lots of people know it. Python is found behind/inside a number of Linux system utilities.
Groovy leaves Perl and Python in the dust when (a) the environment already makes use of a JVM and/or there's a requirement to use existing Java code, including libraries. So far so good. Groovy is not blazingly fast, but faster than Python. Being dynamically typed, it's "fun" and "easy" to program in a way that Java's not.
But then came Scala. Scala is like Java on steroids. It is statically typed so it's not quite as "fun" to program as Groovy, but it has type inference so often you can leave off the types and the compiler can figure them out. Scala works really hard to make the most of types; it does generic types a lot more seamlessly than Java. It dispenses with a lot of Java's boilerplate, so Scala programs are typically about 30% shorter than similar Java programs. Scala runs on the JVM and interfaces pretty well with Java code. It also runs about as quickly as Java, which most of the other languages don't.
Finally in historic order, there's Clojure. Clojure is a Lisp derivative, so it has a programming style very different from languages you'd otherwise know, and it burns through a lot of parentheses! But Clojure runs on the JVM, is very compatible with all the rest of Java, and it's dynamically typed. You can use it as a scripting language or treat it like a compiled language... it's up to you. I find it fun to program in, and the fact that it's an almost pure functional language forces you to think in new ways about programming. It hurts your head at the beginning, but if you survive it's a very worthwhile exercise because you learn some techniques that will become more relevant (I think) in future programming.
In summary, it would probably do you good (put hair on your chest, if I may be so sexist) to learn one or more of these "alternative" / "scripting" languages. You may find them useful. Usually when there's something to be hacked up quickly in my project, I get the job because all my colleagues only know Java, and by the time they finish setting up their class framework I'm already done.
Quote:
so why don´t I just stick with java
and be good at ONE language instead of
having to switch between 2 languages
and their syntax.
This seems like a more general question about learning programming languages than learning a new language (Groovy) which runs on top of the Java Virual Machine.
Here's a question:
Suppose you are learning a foreign language because you want to be fluent in multiple languages so you can converse with many people. You're learning German right now, but you're getting good at it, but you also want to learn Spanish. Would you just suddenly forget German if you start to learn Spanish? If you are indeed worried that you will, what would you do?
If you were going to learn Groovy, but don't want to forget how to write Java, then why not continue to use both languages at the same time?
One of the things about being a programmer is going to be learning to adapt to new technologies as they come along. It's a good thing to be able to learn new languages, as it's going to be a skill that's going to be very useful in a field which is constantly changing.
Why don't you code your desktop apps in groovy too? Just because groovy is the choice of a web framework (grails) doesn't mean that you can't use it for desktop apps.
Indeed, it is great for desktop apps too. It's more a matter of dynamic or static languages...
In my opinion, it is quite good to have for each task the right language at hand. So go ahead and learn groovy - the result will be that you'll miss groovy features when you try to use java again ;-)
I would say in general in this field it's always good to be learning. I try constantly to learn new concepts to add to my toolbox, while getting better at the core things I'm interested in like Java. I recently purchased a book on learning Clojure - another functional language for the JVM.
The downside to learning something without using it every day is that some details don't stick in your head. That said, I'm glad I spent some time with Clojure; the important stuff stuck and I know I can quickly look up the details if and when I need to. You may want to take a similar approach to Groovy.
The Java platform is slowly starting to change direction to one where the JVM is targeted by multiple source languages (a trick .net has been showing off since day 1, but it's taking Java a while to catch up there). The Java7 classfile format is even adding a new instruction to make these dynamic languages work faster.
If you want to keep yourself current, then learning Groovy is a good way to do it, without abandoning all your investment in the Java platform.
Furthermore, Groovy (and Grails) is now maintained by SpringSource, so its popularity is only going to increase.
Going from java to groovy isn't a lot of work. No where near what would be needed to move to a less Javaish language like clojure.
I really like groovy for one-off apps and for scripting existing java code. I've used it to parse data from REST calls and feed the data to a JMS queue. I've used it to create scrambled test data for a partner from our production data. For stuff like that it is amazing.
If the goal is to learn a dynamic language to add to the toolbox, Python and Ruby are both good choices. They run on the JVM and have native versions. Both are well supported on a large number of platforms.
If the goal is to learn an alternative JVM language, groovy is an excellent choice. Both Scala and Clojure would also be good choices.
I used to stick to the "learn a new language every year rule" from The Pragmatic Programmer, but that was before I had kids. Now I learn a new building toy every six months.
First of all I'm this is a highly subjective question.
In my humble opinion it is worth learning a new language especially if it varies in paradigms (as is the case with groovy). I'm fairly young myself so for me learning a new language is not a much of hassle but the way I see it if you like the language, you estimate that coding in language X will be profitable you should learn it.
It won't hurt your resume.
It won't make your head hurt (much).
The only problem is, will you use it. You need to use a language to become good at it. If you are going to learn it now and never use it tomorrow it probably ain't worth learning it.
Learning something new does not take away something you already know. You may be a bit rusty when you get back into Java, but it'll come back real quick.
Also--
I'm not a Java guy, but I believe Groovy targets the JVM. If this is the case, then programming in Groovy will make you a better Java programmer, because you'll still be targeting the same framework as Java (the language) so you'll still continue to gain experience with the Java libraries. Knowing the available libraries is what really matters, not how well you know every minute detail of a particular language.
I find that by learning new languages, I always end up learning new ways to think about problems. Each language guides you into solving problems in the way most easily expressed by the language. Learning new languages only makes you stronger all around because you learn new ways to solve problems.
You might have to re-orient yourself with the libraries after a long time away from a language, but even then it's not a huge ordeal - just more frequent google searches, etc.
The benefits, however, are worth it. I recently did some functional programming for the first time and it really taught me a lot of different ways to think about certain situations. I find myself now using some of C#'s functional aspects and it makes my code a lot cleaner in some cases. The bottom line is; if your going to do this for a living you are going to want to learn more than one language, have you ever met a mechanic that only knew one make and model of car?
It's always good to learn a new language to be a better programmer. Groovy is a natural choice for java programmer - easy to learn and you can still use your all java knowlege.
Groovy is a dynamic language, after try to learn any functional language (like Scala). With this experience you will see java from different perspecitve. Some task that was painful in Java will be trivial in Groovy/Scala.
you can program desktop aplication with Griffon whose language of choice is Groovy, give it a try
If you are looking for online help, check this websites:
for Groovy
for Grails
Just as the title said. What ways do you use to test your own code so that it wouldn't be a boring task? Do you use any tool? For my projects, I use a spreadsheet to list all the possible routines i.e. from the basic CRUD and also all the weird routines. i make about 10 routines.
I get about 2-3 bugs and sometimes major ones by doing this. And if i'm not doing this the client reports another bug.
So tell me what technique do you use in testing your own code in such a way that it doesn't bore you?
Edit:
I forgot to mention that i am particularly working on web based apps and my language is PHP & Cakephp framework.
Have fast tests. The (more) immediate feedback helps to acchieve short iterations. This can almost make you addicted to starting the next test run.
If you find testing boring this is because testing your code is a necessary evil... least is how I perceived you see it.
All you need here is a change in your point of view towards testing... and more specifically... a change in HOW you are testing. You love programming a lot more than testing... well program your tests... then it is just as fun as programming the thing to begin with... and when you are done you have
a program that works
a test suite that remains and test it every builds
So leave that excel sheet and step by step debugger and join the fun :-)
Of course there is more to that and this where test frameworks (junit, testNG, Dunit, NUnit ...) will come in handy, they will take the little pains away and only leave the coding part of the test..
Happy coding and by extension.. happy testing :-)
Few references you may find useful, I am not a PHP expert, far from it but it seemed to fit the purpose.
http://www.simpletest.org/
http://www.phpunit.de/
http://laughingmeme.org/2003/08/05/a-few-tips-for-writing-useful-libraries-in-php/
I used to think the same as you. When I first started programming, we had to work out what the output would be on paper and then do visual comparisons of the actual and expected output. Talk about tedious. A couple of years ago, I discovered Test Driven Development and xUnit and now I love tests.
Basically, in TDD, you have a framework designed to allow you to write tests and run them very easily. So, writing tests just becomes writing code. The process is:
Just write enough to allow you to write a test. E.g you're adding a method to a class, so you just write the method sig and any return statement needed to get it to compile.
Then you write your first test and run the framework to see that it fails.
Then you add code to/refactor your method to get the test to pass.
Then you add the next test and see that it fails.
Repeat 3 and 4 until you can't think of any more tests.
You've finished.
That's one of the nice things about TDD: once your code passes every test you can think of, you know you're finished - without TDD, sometimes it's difficult to know when to stop. Where do your tests come from? They come from the spec. TDD often helps you to realise that the spec. is full of holes as you think of test cases for things that weren't in the spec. You can get these questions answered before you start writing the code to deal with them.
Another nice thing is that when you discover a bug later, you can start reworking your code safe in the knowledge that all of the existing tests will prove your code still works for all the known cases, whilst the new tests you've written to recreate the bug will show you when you've fixed it.
You can add unit tests to existing code - just add them for the bits you're changing. As you keep coming back to it, the tests will get more and more coverage.
xUnit is the generic name for a bunch of frameworks that support different languages: JUnit for Java, NUnit for .NET, etc. There's probably already one for whatever language you use. You can even write your own framework. Read this book - it's excellent.
For new code, work out what the code should do, write a test that asserts that the code does it, work out how to do it, then write the code.
For finding bugs in existing code, a test which reproduces the bug makes it easier to test.
This isn't boring, because in both cases the tests have a high likelihood of failure.
For UAT, then I haven't found any non-boring way - you go through the requirements one by one and make as many tests are required for the functionality. Ideally for new projects, that would have been mostly done up-front as part of the elaboration, but not always. It's only when you're writing tests after the fact that you have to a long list of tests which you already know will pass that it gets boring.
I dont see how it can be boring since it's a large part of the programming itself. Finding and removing bugs is very important, but if you think it's boring maybe you would rather write code in which case you can write a few lines that test critical parts in your code.
Use a test first approach \ pair programming test first.
If you writing them after you have written your own code, then your target is to find mistakes in your work = sad target.
Conversely, if you write your tests before you code, then your target is to write flawless software = happy target.
You probably mean tedious, rather than boring.
If so, this article may help
"No testing, no boring."
Write automatic unit tests, with PhpUnit or Simpletest since you're using PHP, or any other unit-testing framework available for your language of choice. Following Test-Driven Development (TDD), you will build a test suite along with your code. You won't have the impression you're testing anything. Really.
"* test a little, code a little*".
One of the advices I give to my team is that concerning a new features 90% of the logic should run out of the context of the application.
Features that can run outside of the application context are always easy to test.
If you are using .net, you can investigate NUnit.
You can also look at Pex. It seems to be an amazing test framework.
However, your question is a little generic because there are a lot testing types.
Have fun testing :).
I try to write my Tests first and try to design the class around it. So i am really test focussed. I am using JUnit etc.
If you try Programming in that way..testing becomes more and more fun, from my point of view.
I work for a small company yet we have a separate test team. This is because developers are often blind for their own errors, thus they tend to be bad testers.
Our test team is made up of experienced Test Engineers who work according to predefined test-plans and who often use automated test-tools to test the applications we create. (Including websites!) They are not developers!
These testers use TMap for the automated testing. The rest is just manual labor, reading the functional designs and making sure that whatever is mentioned in the functional design will work exactly as described in the final version.
Any errors are reported back to the developers by using an internal bug reporting tool.
Write some unit tests/automated tests, which will run automatically e.g. after a new build has been done.
Use encapsulation and try to test against interfaces only.
Write some small tools to help you test your modules/classes.
Making an easy to use, test suite is easy to do for Perl programs. There is a standard way to do testing in Perl using the Test Anything Protocol.
Basically you write a bunch of files with the .t extension, in the t/ directory of your project, and then run prove.
The files in t/ basically look like this:
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests => 8;
use Date::ICal;
$ical = Date::ICal->new( year => 1964, month => 10, day => 16,
hour => 16, min => 12, sec => 47,
tz => '0530' );
ok( defined $ical, 'new() returned something' );
ok( $ical->isa('Date::ICal'), " and it's the right class" );
is( $ical->sec, 47, ' sec()' );
is( $ical->min, 12, ' min()' );
is( $ical->hour, 16, ' hour()' );
is( $ical->day, 17, ' day()' );
is( $ical->month, 10, ' month()' );
is( $ical->year, 1964, ' year()' );
For more information you can read the tutorial.
There are many languages which have modules designed to work with The TAP, have a look here for more information.
Unfortunately, TAP has only recently been used for other languages than Perl, so there isn't as much support for them, as there exists for Perl.
Do not write tests for trivial stuff - at least not until it breaks i.e. on rare occasion. If you do then you will feel discomfort every time you need to come and maintain those tests. It's absolutely normal, boredom laziness frustration etc. is your natural instinct reaction to pointless work.
Quite opposite, writing tests for non-trivial algorithms & logic, discovering corner cases which you didn't even think about is actually fun and very rewarding experience.