Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
So, I was reading about Bitcoin Script on their official documentation and found this line: "Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops." I tried to reason hard but couldn't understand why would someone make a language "purposefully non Turing-complete". What is the reason for this? What happens if a language become Turing Complete?
And extending further, whether "with no loops" has anything to do with the script being non-Turing Complete?
possible reasons:
security: if there is no loops program will always terminate. user can't hang up the interpreter. if, in addition there is a limit on size of the script you can have pretty restrictive time constraints. another example of a language without loops is google queries. if google allowed loops in , users would be able to kill their servers
simplicity: no loops make language much easier to read and write by non-programmers
no need: if there is no business need for it then why bother?
The main reason is because Bitcoin scripts are executed by all miners when processing/validating transactions, and we don't want them to get stuck in an infinite loop.
Another reason is that according to this message from Mike Hearn, Bitcoin script was an afterthought of Satoshi to try to incorporate a few types of transactions he had had in mind. This might explain the fact that it is not so well designed and and has little expressiveness.
Ethereum has a different approach by allowing arbitrary loops but making the user pay for execution steps.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I have this question - a developer who wrote very complex stored procedures and he/she left the organization. Now you're taking his part and make that same stored procedure to work very fast or like work as earlier to get the same results. What are the steps do we need to follow. In other words, it's like working on someone's impending work.
Stored procedures are notoriously hard to maintain. I would start by writing unit tests - this could involve setting up a dedicated test environment, with "known good" data. Figure out the major logic branches in the procs, and write unit tests to cover those cases. This should make you more familiar with the code.
Once you have unit tests, you can work on optimization (if I've understood your question, you're trying to improve performance). If your performance optimization involves changing the procs, the unit tests will tell you if you've changed the behaviour of the code.
Make sure you keep the unit tests up to date, so that when you leave, the next person doesn't face the same challenge!
First, look at the execution plan of the stored procedure. Make sure you understand why the SQL Server optimization engine choose these plan over another execution plan, which index it used and why, how statistics works, ...
Then, make it better.
Theses are the steps you need to follow.
Understand what's being done
Make it better
Repeat.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have been asked to improve the package performance without affecting the functionality.How to start with optimisation ?Any suggestions
In order to optimize PL/SQL programs you need to know where they spend time during execution.
Oracle provide two tools for profiling PL/SQL. The first one is DBMS_PROFILER. Running a packaged procedure in a Profiler session gives us a breakdown of each program line executed and how much time was spent on each line. This gives us an indication of where the bottlenecks are: we need to focus on the lines which consume the most time. We can only use this on our own packages but it writes to databases tables so it is easy to use. Find out more.
In 11g Oracle also gave us the Hierarchical Profiler, DBMS_HPROF. This does something similar but it allows us to drill down into the performance of dependencies in other schemas; this can be very useful if your application has lots of schemas. The snag is the Hprofiler writes to files and uses external tables; some places are funny about the database application writing to the OS file system. Anyway, find out more.
Once you have your profiles you know where you need to start tuning. The PL/SQL Guide has a whole chapter on Tuning and Optimization. Check it out.
" without affecting the functionality."
Depending on what bottlenecks you have you may need to rewrite some code. To safely change the internal workings of PL/SQL without affecting the external functionality(same outcome for same input) you need a comprehensive set of unit tests. If you don't have these already you will need to write them first.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
So I've read some reports about both of these methods but I can't really grasp the dif between the two.
If anyone could sum it up for me or try to explain it I'd be ever so grateful!
BR, Fredrik
Similar to a car. If you test it, you usually drive it around or at least turn it on. If you inspect it usually you check fluids, maybe pull a spark plug, connect it to a computer and check its settings, fiddle with buttons and switches to make sure there is connectivity. During an inspection you may test the vehicle, but during a test you do not always inspect the vehicle.
Software testing is useful because it allows for a mock up of a production environment to be used in order to see if there are bugs, or errors which either throw exceptions or cause logical errors such as making relationships out of state.
Software inspection is more involved. It can involve testing, but can also involve doing code review to make sure that efficient process is used, and that the readability and maintainability is proper. It helps to make sure that features are properly decoupled, the program is running as fast as possible, and that nothing is going on behind the scenes which is undesirable.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So, I just started a new job a few weeks back. It is my first job doing software, and I have been tasked with learning how a giant project works. Now, the guy before me left NO (zilch) documentation or comments anywhere in the source code. In addition, he applied basically EVERY design pattern in the famous design patterns book by Gamma, etc...
My question is, how do I start? I have tried setting break points for certain calls that I want to learn (learn bit by bit), but because of the 5 million design patterns employed, every call goes up about 7 levels just to finish, and by then, it's hard to keep track of the 20 some objects being created and used.
Has anyone had a similar experience? A few pointers on different methods to try?
Specs: language - VB.net
IDE - Visual Studio 2010
Using - Windows Forms
Brain - Melting
Inheriting a large project without documentation is always a huge pain in the ass. I hope you have already accustomed your manager to the inconvenient truth that it will take several weeks or even months until you can maintain that project efficiently.
I would start with creating some UML class diagrams. That could tell you a lot about how the system works and which design patterns are used where.
While doing so, I would also add comments to the code with everything I learned about it. When I am not sure if I understood what the code does correctly, I would add a common string like "NOT_SURE" to the comment. Later, when I have a better understanding of the system, I could use a text search to find and revise these comments.
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 5 years ago.
Improve this question
Suppose that you are writing or maintaining a piece of code that uses some API that you are not 100% familiar with.
How do you decide whether to read the documentation of a certain call target, and how much time to spend reading it? How do you decide not to read it?
(Let's assume you can read it by opening the HTML documentation, inspecting the source code, or using the hover mechanism in the IDE).
Ideally you should read all of it, but we know that's a pain in the... you know. What I normally do on those cases (and I did that a lot while I worked as a freelancer) is weight some factors and depending on the result, I read the docs.
Factors that tell me I shouldn't read the docs:
What the function does is easy to guess from the name.
It isn't relevant to the code I'm maintaining: for example, you are checking how some code deletes files, and you have some function that obviously does some UI update. You don't care about that for now.
If debugging: the function didn't change the program state in a way meaningful to the task at hand. As before, you don't want to learn what SetOverlayIcon does, if you are debugging the deletion code because it's dying with a file system error.
The API is just a special case of an API you already know and you can guess what the special case is, and what the special arguments (if any) do. For example, let's say you have WriteToFile(string filename) and WriteToFile(string filename, boolean overwrite).
Of course, everything depends on the context, so even those rules have exceptions.