Is there any relationship between a computer science student and DLD course? I am studying BSE and we are studying DLD in my second semester. We've learned so many things about DLD but nothing is related to the CS or SE. It's all about gates and related to Electrical Engineer. Is there any need of DLD in Software Engineering? While the main thing which is concern for us is Programming Languages and Computers System?
Logic is used A lot in programming.
There is little difference between hardware and software. It is just an implementation detail. The choice of what goes where is a balance between cost and speed, but where ever it goes it is just logic: if you implement it in Python, C♯, assembler, HTML, electronics, or mechanical.
You don't say if this is a full course in digital logic or just a part of another course. My own preference would be to make it a part of a course unless the entire program is heavy on engineering.
But, I find a short introduction to digital logic, along with some practice exercises to be useful, provided that the students take away the right lesson.
The lesson that I aim for in teaching Programming Languages and Computers Systems is that a complex system can be properly designed as a series of levels (a stack) in which each level has two properties. The first is that the current level is completely built on just the level below and nothing else. The level below was sufficient in every way to define the current level.
More important, for something like programming languages, is that each level is conceptually complete and completely consistent. Complete means that in order to program you can think at any given level and don't need to consider other things - even the lower levels. Consistent means that you won't find contradictory things at any level.
This means that you can, as a Java programmer, write any conceivable program without thinking about how Java was implemented.
Digital logic is usually taken as the lowest level in this stack - gates. From that we can build more complex things - adders. Adding a bit of physics to that we can build actual machines that act the way the math says the gates should behave. The next level up (perhaps) is machine language (actually microcode these days, but that is just another level). Above that is assembler language, then, perhaps something like C. But each level is complete and consistent. You don't need to think about gates as a C programmer. Nor do you need to know how the Java tools were constructed and whether they are expressed in Java, or C, or assembler.
Each level gives you a mental model that you can work with and the model won't desert you. It is complete and consistent.
The other big idea is that as you go up the stack, the ability to express new abstractions increases. Gates and machine language have no abstraction facilities. Assembler language gives abstractions of simple operations, but little else. Once you reach high level languages you get abstractions for things like functions and objects. You get to define and name complex things and program in terms of those complex things rather than gates.
But some study of digital logic and gates gives you a base on which this is built. It isn't "turtles all the way down".
Well, you would be amazed at the number of times I have reviewed code with a complex condition or nested-if statements where some condition got missed that I flagged by drawing a simple truth table.
However, the big problem is that without a digital logic course you likely won't understand "state machines" and that's a REALLY big deal. And state machines pervade quite a lot of programming.
If you hear the word "protocol", there is a state machine underneath somewhere. If you have "concurrency", there is a state machine. "Parser" or "regular expression"--ayup, state machine. "Agent" or "behavior"--also probably a state machine.
Now, you can design state machines implicitly without knowing that you did. State machines are kinda common sense. But, it's often a lot easier to deal with state machines when you know what you built, can name it, communicate about it, and use tools specifically built to deal with it.
It is really useful to understand the low level operation of the machine when programming in languages like C. Understanding how the digital circuits actually do the work aids understanding of one and two's complement arithmetic, and the relative speeds of integer and floating point operations. Having a sound understanding of the fetch/decode/execute cycle is also useful if you want to develop microcode or assembler.
It is often the case that problems at a software level can only be understood with a knowledge of the digital systems. For example, read through some of this post :-
You might also need to program embedded systems, GPU cards, and control any number of low level devices later in your career. Gaining the understanding for this will depend on knowing the digital design basics.
Most important of all I would say that without this knowledge it is not possible to really understand how a computer works. There would always be a mystery for you regarding exactly how the computer operates.
Hope this motivates a little :)
I hope your course is teaching you skills which will be relevant if you decide to pick up whatever new technology comes along in 10 years time. Some courses might look to be aimed at people who can turn out generic code using whichever language was hot 5 years ago, and it may well be that the digital logic module is unchanged since the 1980's - but that doesn't mean it is irrelevant.
Assuming your course is generic, there are a wide range of career choices that follow the course. Developer - Full Stack might be hot in 2019, but there are plenty of other fields which need a different focus, are not electronics or standard cell design, but benefit from closer understanding of the hardware. You might be working in a cross functional team, and need to speak to hardware folks (or worse, trying to interpret a slightly incomplete specification). You might be making a trade-off between doing work on a CPU, GPU, NN, or FPGA. You might be testing CPU designs. I guess you're unlikely to end up implementing CPU architectures, but other people on your course might.
The course developer doesn't usually know in advance what field you will want to work in, and will usually be trying to avoid closing down your future options (unless the course is tightly focused on training a specific work task).
We've learned so many things but nothing is related to the CS or SE.
Beyond any shadow of doubt, logic is the core skill of any programmer.
Since you're studying BSE, I'll use an example that is common to the field of enterprise software (as opposed to e.g. hardware drivers). For reference, this is a fairly common problem and by no means a fringe case.
I have two date ranges (i.e. each range has a start date and an end date). I want to know if they overlap in any way. Please write the code necessary to evaluate if these two ranges overlap.
If you want a problem situation: You're making an application for hotel reservations and you need to make sure that you don't double book a room. No two reservations can exist for the same room on the same day.
There is no way to not use logic to answer the question. Because you need to account for many different situations. An overlap is created if:
- range1 is fully in range2
- or range2 is fully in range1
- or range1 is before but partially overlaps range2
- or range2 is before but partially overlaps range1.
This is a diagram of all possibilities you need to account for (ignore case 5).
As a coder, you will work out the logic needed for each of the four cases, and then or their results to see if any of them are true. That's the basic approach to checking if one of many conditions is true.
But if you worked it out and knew how to reduce the logic (remove duplicates, negate the logic, or remove things that are invariably proven by an already existing check), you would see that it's much simpler than that:
bool thereIsOverlap = !(range1.end < range2.start || date2.end < range2.start);
And that is a whole lot simpler than fully writing out all of those checks.
It's all about gates and related to Electrical Engineer.
As I mentioned before, logical gates are essential to programming.
The reason you're seeing this in the context of electrical engineering is because that is a very simple context in which to see its practical applicability.
- I want this lamp to turn on while I press the button.
- I want this lamp to turn off when I press the button.
- I want a buzzer to go off when the this button is pressed and another one is not.
Consider electrical engineering as the example scenario, rather than the ultimate goal of the lesson. Because you're not learning about electricity (which is obviously a major part of electrical engineering), you're only learning about logic and how to apply it.
Electrical engineers and programmers both use logical gates, and the principle of understanding them is exactly the same, even if their practical application is for different purposes.
The implementation of any realistic software system is based on electronic elements. Those elements use electricity, generate heat, take up volume, and require propagation time to operate and interconnect.
The more a CS student learns a feel for this physical electronic basis, the less likely they might be to waste time and energy (and thus money) when implementing some software solution. (CO2 emissions and all that for the "politically correct" valuation of a programming solution.)