Python Is Python the Best Language for Electrical Engineering Students?

  • Thread starter Thread starter foges
  • Start date Start date
  • Tags Tags
    Language Python
Click For Summary
Python is widely recommended as an excellent first programming language for electrical engineering students due to its versatility and ease of learning. It is suitable for various applications, including web interaction and scientific computing, making it a practical choice for students. While some suggest exploring other languages like C or Java for a deeper understanding of programming concepts, Python's simplicity allows for a smoother entry into coding. Resources such as official tutorials and beginner guides are available to help newcomers get started effectively. Overall, Python is a strong candidate for those looking to combine programming with electrical engineering studies.
  • #31
mgiddy911 said:
would recommend it to anyone, especially as a first language, however, I would be grateful if someone could give me a good python tutorial (book or website) that is, how should I say this, not boring?

Check out www.byteofpython.info, its for beginners. I am reading my way through it, so i don't know if its a great book, but it seems good enough.
 
Technology news on Phys.org
  • #32
Sun is not doing so well, actually. They opened today at 6.14, which is the lowest of related companies. Their height was 64.3125 back in 2000, right in the middle of the Java boom. While they did increase revenue by 2 billion in 2006, their net income went from -107 million in 2005 to -864 million in 2006. Back in 2003 they lost 3 billion. Even though an increase in revenue is arguably a good thing, Sun has certainly not been in a strong position for a long time.
 
  • #33
Ermm.. 'share price' isn't a good indicator of how well ca company is doing relitave to other comapnys in a sector. Its better to look at Revenue, and Market capitalisation.

Anyway Sun won't go away, its a IT giant, I can't see them going bankrupt unless something eronish happens to them
 
  • #34
Anttech said:
Ermm.. 'share price' isn't a good indicator of how well ca company is doing relitave to other comapnys in a sector. Its better to look at Revenue, and Market capitalisation.

Anyway Sun won't go away, its a IT giant, I can't see them going bankrupt unless something eronish happens to them

You are right, it's not the the greatest indicator for outright comparison. However, Sun is also the lowest of the ten or eleven other top companies competing in the sector if you do a more indepth analysis--Microsoft being number one. Revenue is rather meaningless if you continue to lose money. Share price isn't a good indicator by itself, but combined with losses it is relevant.

Sun does look like they could turn around, but it is doubtful if they continue their pattern of losses.
 
  • #35
chroot said:
Python is even more flexible than Java in terms of inter-platform compatibility, because it not only runs anywhere...

I don't understand this, they both work using the same underlying princple of intepreting virtual instructions at run time... how can one be more flexible than the other?

Perhaps Python has been implemented on some major platform that Java has not and I am just not aware of it...
 
  • #36
eieio said:
You are right, it's not the the greatest indicator for outright comparison. However, Sun is also the lowest of the ten or eleven other top companies competing in the sector if you do a more indepth analysis--Microsoft being number one. Revenue is rather meaningless if you continue to lose money. Share price isn't a good indicator by itself, but combined with losses it is relevant.

Sun does look like they could turn around, but it is doubtful if they continue their pattern of losses.
Yeap.. can't disagree with that. Sun arent as good as they once were, but they are still a huge company with some VERY good products.

Anttechs would put Sun as *Sell* right now :) But not forever.. I think they are a good enough outfit to come back, with a strong *geek* techncial appreciation, perhaps not from this board but elsewhere for sure, they will be bale to make inroads back into the Server, and application market..
 
  • #37
Java isn't open sourced, Python is.. I have a sneaky feeling this is a cloaked props to the GNU community :wink:
 
  • #38
Anttech said:
Java isn't open sourced, Python is.. I have a sneaky feeling this is a cloaked props to the GNU community :wink:

However, key Java implementations such as SE, ME and EE are open source.
 
  • #39
SE, ME, EE are what exactly?

Im a network engineer not a programmer.
 
  • #40
SE is the Java version (libraries and virtual machine) that you can use to run desktop programs on your PC.

ME is the Java version that runs on your mobile device (specialied libraries and virtual machine)

EE is the Java version that works on Servers (or on your desktop) (imagine as an upgrade to the SE version) it provides libraries and services for web based solutions.

There is nothing sneeky about Java, all what you are required is to acknowledge that Sun is the author of Java how you use Java technology is your own thing. But if that is to much to ask...then there are other alternatives or you can always write your own language.
 
  • #41
I don't mean to derail the thread, but I have to disagree with Anttech's comment about share prices.

Most investors feel that the share price essentially "encapsulates" every piece of available knowledge about a company, and thus that the share price is the most meaningful indicator of a company's health. Investors essentially vote with their money, and the bears and the bulls (with various amounts of knowledge about the company) fight until a consensus is reached in the share price. Many investors believe that everything known about a company is "baked into" the share price.

- Warren
 
  • #42
mgiddy911 said:
I have just never been able to get inot python, I love Java, and would recommend it to anyone, especially as a first language, however, I would be grateful if someone could give me a good python tutorial (book or website) that is, how should I say this, not boring? or rather is indepth and has a lot of applications besides the standard "Hello world!" I guess I just need to get past the first few chapters in python to begin to like it more

Python's actually a CS geek's wet dream -- it's full of interesting and important and exciting features that are totally absent in many other languages. Look up "list comprehensions," and let me know if you don't find them un-boring.

If you tell us what resources you used to learn Java, I'm sure we could find some similarly un-boring resources you can use to learn Python.

- Warren
 
Last edited:
  • #43
chroot said:
I don't mean to derail the thread, but I have to disagree with Anttech's comment about share prices.

Most investors feel that the share price essentially "encapsulates" every piece of available knowledge about a company, and thus that the share price is the most meaningful indicator of a company's health. Investors essentially vote with their money, and the bears and the bulls (with various amounts of knowledge about the company) fight until a consensus is reached in the share price. Many investors believe that everything known about a company is "baked into" the share price.

- Warren

Your assuming a perfectly efficient market system. Market is price is more a popularity contest than a real indicator of underlying value. There are countless fine companies with lame stock prices. Also remember that institutional trading has a lot to do with stock prices as well. It's far from a perfectly valued market.
 
  • #44
Ronnin said:
Your assuming a perfectly efficient market system. Market is price is more a popularity contest than a real indicator of underlying value. There are countless fine companies with lame stock prices. Also remember that institutional trading has a lot to do with stock prices as well. It's far from a perfectly valued market.

I'm well aware of the efficient market hypothesis. The truth is that, for large, well-known companies like Sun, the market is essentially perfectly efficient.

- Warren
 
  • #45
chroot said:
I'm well aware of the efficient market hypothesis. The truth is that, for large, well-known companies like Sun, the market is essentially perfectly efficient.

- Warren

Well we've gone off topic of the thread here but all I can say is that investor sentiment can turn on a dime. Companies fall in and out of favor with investors but yet the companies have esentially stayed the same. Speculation for things that may or may not happen is also "baked-in" to a stock's price as well. I guess every investor takes that risk on how "efficient" they think their stock's price is.
 
  • #46
Since this is already way off topic...

I think with Sun we could make a lot of arguements of how their stock price has been affected by things that would indicate a not so great position for the company thus making the initial point.

Sun is not in a strong position in the market, and really haven't been.

Stock price peaked in 2000. Notice what else did?

Net Income:
2000 $1.8b
2001 $927m
2002 $(587)m
2003 $(3.4)b
2004 $(388)m
2005 $(107)m
2006 $(864)m

While I'm not attempting to say that net income or stock price says it all or even a majority of it, we can see a clear correlation between the company being profitable and their stock price...so yes, stock price is an indication of something...

In all reality, even popularity has meaning. A non-popular company is not as likely to be as profitable. Point is: stock price *can* indicate the strength of a company. In the case of Sun, I think it does. Even if we call it all a popularity contest.
 
  • #47
Let's throw some data on the fire: According to the Wall Street Journal, Sun's five year Price Performance versus Industry (Dow Jones Computer Hardware) is around -53.90%. There is a weak uptrend in this starting late calendar 2005, but not as strong as the sector or the overall market. For comparison, Dell's performance over the same period presently stands at -7.14%; Hewlett Packard is +83.36%, and Apple is +810.21%. Sun is about exactly halfway down the chart in this category.

Sun certainly projects a certain gloom, as if it's got one foot in the land of the long lost RISC dino-vendors. Java probably is not enough to keep them afloat.

In principle, share price is the sum of all future earnings discounted to the present. The principle fails because 1) you can't know the future earnings, 2) you don't know how interest rates will vary in the future. But analysts do try: stock prices are not purely arbitrary popularity contests.
 
  • #48
Most investors feel that the share price essentially "encapsulates" every piece of available knowledge about a company, and thus that the share price is the most meaningful indicator of a company's health.
I don't dissaggre, but it isn't a good way to compare companys

IE Cisco's share price maybe 20$/share and RBS maybe 2$/share, but RBS could still be a more healthy and profitable company but its capitisation is different than that of Cisco.. This is what I was meaning
 
  • #49
chroot said:
Sun itself may well go away one day (this is also looking quite likely), and Java will hopefully follow it to the grave.

I'm really quite surprised by the volume of people that still think (1) Sun is dying and (2) Sun is still exclusively a RISC vendor, first and foremost; however, nothing would really be further from the truth. Sun has become a very serious AMD64 vendor, and in my opinion, one of the better ones, if not the best. Their AMD64 servers have massive density, processor, IO, and memory-wise.

Do you see Dell, IBM,. etc putting out anything like this?

http://www.sun.com/servers/x64/x4500/
http://www.sun.com/servers/blades/8000/

And likewise, while Sun is nowadays an AMD64 vendor, they still haven't forgotten about SPARC. The road for SPARC development seems to be massively threaded systems and processors, like the T1000 or T2000, with an UltraSPARC-T1 that supports up to 32 simultaneous threads:

http://www.sun.com/servers/coolthreads/t2000/

Keep in mind, the T2000 will outperform most of the SPARC mid-range and AMD64 servers on certain workloads, namely those that aren't floating-point intensive and are highly parallel. This seems ideal for database and web serving workloads, and the benchmarks indicate this, as well.

Lastly, Solaris 10, which was released 2 years ago has features that Linux is trying to implement (and failing horribly) and features that Linux won't be able to implement if ever because of inherent design flaws. Systemtap (which is the equivalent of Solaris' DTrace) is at the mercy of Linux kernel API compatibility, which if anyone has ever written a driver in Linux -- it amounts to searching through headers, finding an interface, and praying that interface won't be deprecated in the near to remote future. Volume mangement sucks on Linux, pure and simple, whereas ZFS has completely re-written the book on storage and filesystems. (Take a look at http://opensolaris.org/os/community/os_user_groups/os-presentations/zfs.pdf if you don't believe me)

So, before you say Sun is dead or dying, take a look around at the market. You'll find a number of technologies that Sun is sharing with the rest of the community that no one else has, and plenty of people are interested in them. There have been large Solaris 10 deployments on Wall Street and FedEx is very interested in Solaris 10, as well. In fact, FedEx has used DTrace to analyze a number of their in-house applications, which led to improved performance.
 
  • #50
Warren, I am finding your extreme Python zealotry a little tiring. I believe that it stifles constructive comparison. Can you please consider that other people here also have a lot of experience? We are interested in your ideas, but not in having them pushed down our throats.
 
  • #51
While I see the utility of Python, I do not like the language. I do not like it at all. (And yes, unlike green eggs and ham, I have tried it.) I find the use of indentation to indicate program structure and the lack declarations to be abominations. Indentation and mistyping identifiers are two of the common mistakes made by programmers. The first computer languages did not require that variables be declared. Later languages added the requirement that things be declared before they are used precisely because of debacles with these early languages. It seems the developers of Python forgot (or never learned) some very important lessons-learned in the development of computer science. "Those who don't know their history are doomed to repeat it."
 
  • #53
harborsparrow said:
Warren, I am finding your extreme Python zealotry a little tiring.

Uh, the last time he posted in this thread was more than two and a half years ago.
 
  • #54
D H said:
While I see the utility of Python, I do not like the language. I do not like it at all. (And yes, unlike green eggs and ham, I have tried it.) I find the use of indentation to indicate program structure and the lack declarations to be abominations. Indentation and mistyping identifiers are two of the common mistakes made by programmers. The first computer languages did not require that variables be declared. Later languages added the requirement that things be declared before they are used precisely because of debacles with these early languages. It seems the developers of Python forgot (or never learned) some very important lessons-learned in the development of computer science. "Those who don't know their history are doomed to repeat it."
Pythonistas respond that the mistake is in relying on compiler type checking to catch programming errors. Code must have use test cases alongside, compilers and type declarations are no substitute.
 
  • #55
Riiiight. As if that is how Pythonistas really worked. Very few organizations achieve 100% code coverage, far fewer achieve 100% path coverage.

Even if Pythonistas are the most thorough of all testers, it is a stupid concept. The earlier errors are caught the cheaper it is to repair them. This approach defers error detection until testing, or even worse, post deployment.
 
  • #56
D H said:
Riiiight. As if that is how Pythonistas really worked. Very few organizations achieve 100% code coverage, far fewer achieve 100% path coverage.

Even if Pythonistas are the most thorough of all testers, it is a stupid concept. The earlier errors are caught the cheaper it is to repair them. This approach defers error detection until testing, or even worse, post deployment.
I'm afraid you missed the coding train on this one. The Big New Thing is to write the test code _before_ the code code, and it is common in both Python and Java, and increasingly enforced in large scale projects. I was raised otherwise, but it completely changes the approach to coding. One sets up this entire suite of tests, they all fail initially, and one by one as the code comes up to speed the tests come back Ok. The practice also eliminates the "we'll get to the tests later" procrastination.
http://www.junit.org
http://docs.python.org/library/unittest.html
http://docs.python.org/library/doctest.html
The entire python library is tested in this way.
 
  • #57
D H said:
Even if Pythonistas are the most thorough of all testers, it is a stupid concept. The earlier errors are caught the cheaper it is to repair them. This approach defers error detection until testing, or even worse, post deployment.

D H,you're missing the coding train in more ways than one. One of the most central tenets of Python is duck typing, which means that a given object's current set of methods, fields, etc. determine how it can be used. Objects in Python do not have explicit types; instead, if they express the methods and fields of a some type A, then they can be used as if they were type A. There's no reason to give objects explicit strong types, because most of the objects people write in the real world naturally end up being multi-faceted anyway.

This mechanism is just as strong as actual strong typing, yet provides enormous flexibility. It allows any object to be used in any desired way simply by defining the appropriate methods or fields. You want your data structure to be iterable? Just define a few methods. Any code that attempts to use your data structure in an unintended way will generate a run-time error, which can be caught and handled appropriately.

Strong typing doesn't necessarily make code less bug-prone, and I challenge you to find any studies that claim such a thing. Strong typing is just a poor man's substitute -- an easy to implement, but unduly restrictive substitute -- for real introspection, where one piece of code is actually aware of what another piece of code can do.

That's not to say that strong typing does not have its place. If I were writing code that goes into aircraft avionics, I'd definitely be using a language with strong typing, because it prevents the (extremely rare) possibility of misusing an object that just happens to define methods to make it look like something it is not. In practice, I have never run across such an "impostor" object in years of programming Python, so it's really a non-issue.

- Warren
 
  • #58
D H said:
Even if Pythonistas are the most thorough of all testers, it is a stupid concept. The earlier errors are caught the cheaper it is to repair them. This approach defers error detection until testing, or even worse, post deployment.

Yes, it's such a stupid concept that Google uses it extensively, and we all know how stupid the Googlers are, right? And how terribly awful their software is, right?

- Warren
 
  • #59
harborsparrow said:
Warren, I am finding your extreme Python zealotry a little tiring. I believe that it stifles constructive comparison. Can you please consider that other people here also have a lot of experience? We are interested in your ideas, but not in having them pushed down our throats.

If I were your boss, and I were forcing you to use Python instead of some other language, then I might fairly be accused of pushing Python down your throat.

Instead, I'm just some guy posting on an internet forum. I'm allowed to promote any language I like with the fervor that I believe it deserves. Everyone else here is permitted the same freedom of expression. Get a grip.

- Warren
 
  • #60
chroot said:
That's not to say that strong typing has its place. If I were writing code that goes into aircraft avionics, I'd definitely be using a language with strong typing, because it prevents the (extremely rare) possibility of misusing an object that just happens to define methods to make it look like something it is not.
Well, welcome to my world. Strong typing is just a start. Algorithms must provably run to completion in a fixed amount of space and time. A garbage collector deciding to rear its ugly head would be problematic, but fortunately there is no need to worry about garbage collection in avionics software: Memory allocation is strictly verboten. Python violates many precept of avionics software.
 

Similar threads

  • · Replies 8 ·
Replies
8
Views
2K
  • · Replies 10 ·
Replies
10
Views
3K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 8 ·
Replies
8
Views
2K
Replies
5
Views
2K
  • · Replies 9 ·
Replies
9
Views
2K
  • · Replies 11 ·
Replies
11
Views
3K
  • · Replies 56 ·
2
Replies
56
Views
10K
  • · Replies 15 ·
Replies
15
Views
3K