how is the job prospect of FPGA or Labview? - Page 1
Forum section: electronics / beginners

author: david-IT
author_rank: Contributor
timestamp: March 29, 2016, 10:05:38 am
content: i am a begineer of FPGA,and know Labview,now i want to improve myself that proficient at.Can anyone tell me how is the job prospect of FPGA or Labview?Thanks very much

author: tggzzz
author_rank: Super Contributor
timestamp: March 29, 2016, 10:33:07 am
content: Quote from: david-IT on March 29, 2016, 10:05:38 amThe half-life of knowledge about any particular tool is a few years at most. If, say, it is 3 years then in 9 years 87.5% of your knowledge is obsolete. (FPGA example: how much use is knowledge of Xilinx's ISE, now that Vivado is "the future").Knowledge of fundamental principles can and does last a lifetime.If you want to find out how many companies are hiring people with experience of X, look at the job adverts. Of course, by the time you have learned X, the market may have moved onto X2 or Y.

author: danadak
author_rank: Super Contributor
timestamp: March 29, 2016, 11:23:12 am
content: C Language has had a 44+ year life, but prior poster right onconcerning IDEs. ASM langauge, for some processors, like Intel 8051that will not die, now ARM, stay current for a large number of years.The good news is that vendors tools in any specific technology seem to"merge" in adaptability for the user. That is to say user can jump fromtool to tool, once experienced in one tool, and be able experience a fastlearning curve for user. That's because increasingly the tools are GUI andprovide a lot of the "mundane" IP that no longer has to be re-inventedevery time a new project is started.Labview seems to have taken on a new life for low cost rapid turn interfaceto instruments, sensors. A quick way of getting a custom GUI together forproduct operation. New is Python, but on a wider application basis.Regards, Dana.

author: tggzzz
author_rank: Super Contributor
timestamp: March 29, 2016, 11:57:52 am
content: Quote from: danadak on March 29, 2016, 11:23:12 amAs someone that started writing C in 1981 when there were a total of two books on the language, I can assure you that C has mutated almost out of all recognition - and not always for the better.QuoteGUIs have very little to do with it.The fundamentals are the same no matter which IDE tool is used. All that changes is where the buttons are, or what the command line options are.Even languages are very similar to each other, within broad groups. For example, there is a strong common thread from Smalltalk->Objective C->Java->C#. Thesyntaxchanges, but thesemanticshave remained largely unchanged over 30 years. Once you know one proficiently, it is very quick to use another proficiently.OTOH, there is more of a problem switching to any of the FSM languages, or Lisp, or Prolog, or C.

author: danadak
author_rank: Super Contributor
timestamp: March 29, 2016, 01:41:36 pm
content: QuoteInteresting. I started with Fortran, early 70's, then several ASM, mini's, Test Systems (morethan once I had to code the system to discover its HW language, horrible docs), then someBasic, started late on C. Now working on Verilog and Python, at a snails pace I mightadd.I found that GUIs eliminated, largely, need for command line execution, or need to learnits own language. Which frankly after punching tons of cards and paper tape were a blessing.Then we got good editors, then finally drag and drop components with attached code baseattached to the GUIs. And about the same time debuggers/JTAG/OnChip debug, again allwrapped around GUIs. So for me going from one un-guied toolset to another is like tryingto climb Everest, as opposed to the ease with which I adapt to a language supported by aGUI.So I guess our definition of what a GUI does probably an expression of experience.QuoteFor me learning C was a disappointment, but a necessity. So strongly typed. I am fascinatedby your comment it is unrecognizable from origin, I thought it so simple already how couldit have evolved much. I will take your word for it.Regards, Dana.

author: krivx
author_rank: Frequent Contributor
timestamp: March 29, 2016, 02:58:30 pm
content: Quote from: danadak on March 29, 2016, 01:41:36 pmYeah, I agree. I learnt C relatively recently (at least compared to people in this thread) but I can read K&R just fine.

author: tggzzz
author_rank: Super Contributor
timestamp: March 29, 2016, 04:23:20 pm
content: Quote from: danadak on March 29, 2016, 01:41:36 pmWell, you have chosen to omit the point I was making, and have started down a different track. I agree with all you say about GUIs, except that command-line options are preferable for automated build and test systems where multiple people are working on the same codebase. However that doesn't invalidate the point I was making.BTW, FWIW Iactuallystarted with Algol-60, five channel paper tape, 5cps telytypes, and a 2kIPS 39-bid machine.QuoteC data is completely untyped; that is one of the reasons C is so useful and is still used. C variables are typed, but the typing can be - and often is - overriden.Contrast that with Smalltalk and Java (and the decent bits of C#) where the data is strongly and unbreakably typed.QuoteA starting point would be to look at the number of reserved keywords. Then add their interaction. And the latest variant finally has a memory model, although who knows when that will becompletelyimplemented andused.For amusement, have a look at the FQAhttp://yosefk.com/c++fqa/which has a lot in common with C, of course. I'm particularly amused by the "const" sections, since I remember the unresolvedand unresolvablediscussions as to whether it should/must be possible to "cast away constness".

author: tggzzz
author_rank: Super Contributor
timestamp: March 29, 2016, 04:33:30 pm
content: Quote from: krivx on March 29, 2016, 02:58:30 pmI haven't seen K&R C indecades. You know, the C whereCode:int foo(int baz, int bar) {/* body omitted */return 0;}won't compile due to a syntax error, whereasCode:int foo(baz, bar)int baz;int bar;{/* body omitted */return 0;}is OK.

author: danadak
author_rank: Super Contributor
timestamp: March 29, 2016, 07:11:58 pm
content: What did you mean by this -QuoteI understand the overidden, eg. compiler intervention, and I think of the wiki def of typing as defined function call vars typed,but "data is completely untyped" ? By this irrespective of defined typing do you mean by itself data has no meaning until wethe programmer define what it is ? Or am I missing the meaning altogether ?Back to the original point,QuoteMy way of thinking is the GUI is like the original horesless carriage, without a body it was a pain to drive in a snow or rainstorm.And when it came along not only did the body come but many additional capabilities. I agree fundamentals did not change, eg.engine, wheels, etc.. but how much better the ride is now. Maybe we are arguing the horse before the carriage problem, forwhich I still am severly confused......Quite familiar with teletype, main I/O on PDP-8 I used to test ICs. Not to exclude switch/light panel.Regards, Dana.

author: tggzzz
author_rank: Super Contributor
timestamp: March 29, 2016, 07:33:58 pm
content: Quote from: danadak on March 29, 2016, 07:11:58 pmIn C, the data is one or more bytes, and the meaning of the bytes is determined by whatever is "looking at" and "interpreting" the bytes. Hence 0x01, 0x02 could be a unicode character, 258 decimal, 513 decimal, or a pointer to a function, or.... That is most clearly visible when one thinks of casts, ofattemptingto interpret core dumps, or when you point your debugger at a random piece of memory. In the debugger you have to tell the debugger how to interpret the bytes usually by accessing it in the context of a typed variable - but if the type is wrong, you simply won't know it is wrong.In contrast, in Java/Smalltalk/C# etceverypiece of data has auniquemeaning defined by an associated "class pointer" or similar. Thus it is impossible to cast a horse into a camel, and no way to "downcast" an animal into a horse unless the animal really is a horse - it if was a camel then there would be a runtime "ClassCastException". Requiring every piece of data to also have a class pointer increases the memory footprint, of course, but in many circumstances that is of less concern than correct program operation and graceful recovery when the unexpected occurs. When in the debugger, you are offered the exact set ofvalidoperations on the data.

author: david-IT
author_rank: Contributor
timestamp: March 30, 2016, 10:26:04 am
content: Quote from: tggzzz on March 29, 2016, 10:33:07 amyes,you are right,thanks very much,i will work hard to learn

author: david-IT
author_rank: Contributor
timestamp: March 30, 2016, 10:28:29 am
content: Quote from: danadak on March 29, 2016, 11:23:12 amyes,the Python is widely used now,i just learned front-end language and php,the knowledge changed so fast

author: david-IT
author_rank: Contributor
timestamp: March 30, 2016, 10:30:47 am
content: Quote from: tggzzz on March 29, 2016, 11:57:52 amC is interesting sometimes,but sometimes it is a little difficult.Now the software seems more popular

author: krivx
author_rank: Frequent Contributor
timestamp: March 30, 2016, 10:41:11 am
content: Quote from: tggzzz on March 29, 2016, 04:33:30 pmI meant the reading the book, but these examples are very similar. I don't see how one has mutated out of recognition, it usually seems more like project-specific coding styles/standards have more impact on the code than which C language standard it was written against.

author: david-IT
author_rank: Contributor
timestamp: March 30, 2016, 10:59:05 am
content: Quote from: tggzzz on March 29, 2016, 07:33:58 pmfor software,php seems popular now

author: tggzzz
author_rank: Super Contributor
timestamp: March 30, 2016, 01:25:04 pm
content: Quote from: krivx on March 30, 2016, 10:41:11 amSigh. That was a trivialexampleof one difference.Please find "little things" like volatile, sequence points, the memory model , const (and many many more) anywhere in the first two books.Most importantly, in the first two books there were never any arguments (let alone interminable arguments) about what the code would do after compilation. Now the standardsare a bloated mess that require language lawyers. And even then they often misinterpret and/or fail to agree on what is stated.

author: krivx
author_rank: Frequent Contributor
timestamp: March 30, 2016, 05:27:42 pm
content: Quote from: tggzzz on March 30, 2016, 01:25:04 pmI think any failure of the standards is mostly due to the many cases that result in undefined behaviour. I think a lot of that could be deliberate for performance reasons but I don't really know enough about the compilers to be sure.As for volatile, sequence points, const etc I guess I don't find that too cryptic as it was introduced when I leant the language originally, I have the opposite view.Most additions seem necessary, I can't see embedded programming working too well with optimizing compilers without a volatile model for example. cdecl (http://cdecl.org/) and static-analysis tools get me over the rest of it.C++ is a different kettle of fish.

author: jpb
author_rank: Super Contributor
timestamp: March 30, 2016, 06:27:53 pm
content: Totally off topic, but this thread has made me feel young! I started programming in FORTRAN in 1979 (punched cards handed over to computer operators) and didn't switch to C until the mid 1980s!It is good to see others who started even earlier.

author: tggzzz
author_rank: Super Contributor
timestamp: March 30, 2016, 07:00:36 pm
content: Quote from: krivx on March 30, 2016, 05:27:42 pmThere are various reasons, but deliberately leaving something undefined for performance reasons would be peverse. It would lead to getting the answer faster but not being sure that it was the right answer or a repeatable answer. And if you don't have to get the right answer, you can make the progam infinitely fastOne of the prime reasons for leaving something undefined is because there are irreconcilable differences between what it does on one processor and another. Another is that it would be excessibel slow on some architectures. Another is that getting it right would break some existing programs. And of course, sometimes it is just too difficult to get all parts of the spec to agree with each other.And be careful about the difference between "undefined" and "implementation dependent". The former is the cause of nasal demons, the latter is the cause of subtle portability problems.QuoteJudging by the statements of those that were on various national committees, you think you understand them, but you don't. The problems come with the corner cases, with optimisation, and with feature "interaction".First example that comes to mind... C (until possibly the latest spec) defined anythign to do with multithreading as outside the language spec and being the libraries' responsibility. Therefore POSIX has to rely on C features that are deliberately not defined.Remind me, can you "cast away constness". There were endless (i.e.yearslong) debates about whether it must be allowed (for libraries) or must be prohibited (to allowknown correctoptimisations). I believe it is allowed, but the existence of the debate demonstrated that the language was being pulled in two incompatible directions and was out of control.QuoteYes. See the FQA, which is most entertaining - unless you have to deal with it. (Bits are relevant to C, of course).For myself, I decided in 1988 that if C++ was the answer, I thought the question was wrong ;} Cue story about how thedesignersdidn't understand the template language was itself Turing-complete, until someone wrote a short program that caused thecompilerto output the sequence of prime numbersduring compilation. If the designers don't understand their creation, what hope do the rest of us have.

author: krivx
author_rank: Frequent Contributor
timestamp: March 30, 2016, 07:13:53 pm
content: Quote from: tggzzz on March 30, 2016, 07:00:36 pmI understand it's not the point you were making but "casting away const" seems like a pretty bad idea. I can't think of a reason to do so other than legacy libraries.I just tried it inhttps://gcc.godbolt.org/and it appears to compile OK. So it seems it can be done, but I probably shouldn't do it. Interesting example.

author: tggzzz
author_rank: Super Contributor
timestamp: March 30, 2016, 07:44:47 pm
content: Quote from: krivx on March 30, 2016, 07:13:53 pmI was using the term "library" far too loosely. Think of systems level or "meta" programming, e.g. a debugger where you want to change the value of something declared const. If you prefer a higher level topic, consider reflection in a dependency injection framework.Of course, more coherent languages manage that in a typesafe way, which is one of the reasons they are so popular and commercially important.