Python 3 is the first backward-incompatible version of the Python programming language. This incompatibility was intentional and necessary in order to fix a number of issues with Python 2. However, there are a number of Python developers who aren't happy with the changes introduced in Python 3. These complaints are reflected in the seemingly poor adoption of the next-generation Python. This didn't exactly come as a surprise to the creators of Python 3. This is why support for Python 2 will continue for years to come.
I'll admit, I wasn't exactly elated that Python 3 wouldn't be compatible with Python 2 applications. Who would be? You've spent months or years working out intricacies to yield a stable Python 2 application. This incompatibility would dictate that you throw it all away. Well, maybe not exactly, there are upgrading utilities to help convert Python 2 code to Python 3 code. Obviously this isn't going to fix the larger problem of not having supporting frameworks and libraries.
The selection of available Python 3 packages on pypi is slim but growing. Some important web application frameworks like Django and Twisted are missing. Developers that rely on these frameworks obviously aren't going to adopting Python 3 anytime soon. So why aren't these frameworks adopting Python 3? Because it is hard. It isn't exactly trivial to build a well-established, stable framework even in Python 2 which has been around for a while. Most of these frameworks will be Python 3 based at some point in the future while others probably have no intention of adoption.
In the mean time, write some Python 3 code that doesn't rely on frameworks. This is probably the best way to get familiar with the language. If you know another Python developer, show them some cool things you get working in Python 3. Also show them stuff that doesn't work. This all leads to more Python 3 code coming into existence. This could be a good opportunity to write a new framework for Python 3. Remember, there are many benefits brought about by the changes made in Python 3 that outweigh the familiarity of constructs you're used to using in Python 2.
Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts
Tuesday, May 4, 2010
Friday, April 23, 2010
Designing Code
Designing code is one of the most essential jobs of a programmer. That is, programmers do more than just design code. They also write it, document it, and read it. Hence, the term writing code. You never hear a programmer say they're going to spend some time designing code. It is writing code that matters. You could design software for several months and it wouldn't make a world of difference in the mind of a programmer. If no code has been written, no progress has been made.
This is where programmers actually are designing, while they are writing code. When they are sitting there with an editor open, they can see what needs to happen in order to solve the problem at hand. In fact, it is even easier for programmers to debug existing code rather than start from scratch and right something completely new. There is something about code that enables us to see structural and behavioral design and that serves as a reference in our mind.
But every programmer has a different logical representation of the system at hand in their own mind. Two perfectly acceptable solutions to a given problem may be completely incorrect to two opposing programmers. How can this be? Even in the same programming language, two wildly differing solutions are available to solve the same problem. The problem is that in software development, the problem at hand is never just the problem given to us. There are too many environments in the computer universe in which software may run.
These problems given to programmers to solve are only the half of it. The stakeholders really don't care that system X doesn't support interpreter Y and therefore cannot use language feature Z. Programmers will find a way around these limitations. But the problem is that unless you are the programmer doing the implementation, you really can't wrap your head around the full details of implementing a full solution. It really comes down to the fundamental software development concept of having a separation of concerns. Stakeholders in software development projects don't necessarily need to know all the low-level implementation details. They just need to be aware that they exist.
This isn't always the case with stakeholders. Imagine you had an environment in which to implement their solution aligned with what the stakeholders sometimes envision; you write the code to solve their problem and there are no implementation surprises. In a scenario like that, writing code to directly solve their problem is a feasible approach. But that will most definitely not happen any time soon, if ever. So in the mean time, we are stuck dealing with implementation details that fall outside the scope of the business problem.
When programmers write code, they have two tightly-coupled problems. There is the problem of making the software do what it was intended to do, the business problem. There is also the problem of the the other, unforeseen implementation details, the implementation problem. When we begin to write code for the business problem, the implementation problem doesn't really exist yet. How can it? These are unanticipated problems. They don't come into being until you can see them. This makes sense to a certain extent because if you start thinking about potential implementation problems too much before some design activities have started, no code would ever be written.
So what is the real benefit to separating these two problems, if any? It doesn't seem very obvious what the exact benefit of separating the business problem from the implementation details is at first. But one problem with not doing so is apparent. Since implementation detail problems do not really exist until the code is being written, they often affect the business problem implementation once they come about. That is, if a programmer spends time designing some ideal code for the business problem, depending on how specific that design is, an implementation detail problem could put the whole design in jeopardy.
Since code is so tightly coupled with the implementation of a running system, a good way to represent the business problem is with a model. A model is not part of the running system but it is an artifact of the process used to create the running system. UML models are a good way to represent any given software system. They can show almost any level of detail one might be interested in seeing. There is, however, a similar problem with models. You have the ability to start getting into implementation details.
This goes to show that modeling your code before actually writing it isn't a magic way to fix your code design. The common problem with creating models is that they tend to evolve too quickly without writing any code. If the level of specificity in your model gets too high, you've not only taken a waterfall approach but you're also taking a risky path by assuming there will not be any seemingly small implementation issues. Models are a good way to start off the business domain model as long as they are general enough. The level of specificity cannot be too high before code is written. Even then, it doesn't need to delve into too much detail just for the sake of it. Model details are better left out until they become a requirement.
Now lets take a step back and think about this for a moment. We now have a business problem that we're going to solve with software. In order to build this software, we need to write code that will implement the solution to the business problem. We know that there are going to be changes because our computing environments are disparate enough that we has humans cannot predict exactly how our code will behave. In order to help distance our business problem from any potential implementation problems, we build a high-level model of the business problem.
We should now be all set to start coding and hope for the best, right? Starting to code is definitely the right answer. Hoping for the best suggests an uncontrolled level of uncertainty. This can be at least somewhat controlled by expecting unexpected implementation details. Remember that your code and your model will always change throughout iterations of the project. The model you build will also have some overlap with the implementation. This is necessary unless the stakeholders are only expecting a model of the software and not the software itself.
Once these implementation detail issues do exist, is it worth modeling these issues? Only if it is separated from the business problem within the model somehow. It might even make more sense to create a completely separate model for implementation details. But only if it adds value. Modeling the nuances of implementing software isn't an exact science because chances are, these same details will become irrelevant in five years.
To sum this all up, remember that there is value in upfront code design centered around the business problem at hand. This doesn't necessarily mean modeling, it could be as straightforward as prototyping a command line interface simply for the purpose of testing how well the abstractions in your domain work. Modeling does offer a visual design aspect that often cannot be gleaned from code itself.
This is where programmers actually are designing, while they are writing code. When they are sitting there with an editor open, they can see what needs to happen in order to solve the problem at hand. In fact, it is even easier for programmers to debug existing code rather than start from scratch and right something completely new. There is something about code that enables us to see structural and behavioral design and that serves as a reference in our mind.
But every programmer has a different logical representation of the system at hand in their own mind. Two perfectly acceptable solutions to a given problem may be completely incorrect to two opposing programmers. How can this be? Even in the same programming language, two wildly differing solutions are available to solve the same problem. The problem is that in software development, the problem at hand is never just the problem given to us. There are too many environments in the computer universe in which software may run.
These problems given to programmers to solve are only the half of it. The stakeholders really don't care that system X doesn't support interpreter Y and therefore cannot use language feature Z. Programmers will find a way around these limitations. But the problem is that unless you are the programmer doing the implementation, you really can't wrap your head around the full details of implementing a full solution. It really comes down to the fundamental software development concept of having a separation of concerns. Stakeholders in software development projects don't necessarily need to know all the low-level implementation details. They just need to be aware that they exist.
This isn't always the case with stakeholders. Imagine you had an environment in which to implement their solution aligned with what the stakeholders sometimes envision; you write the code to solve their problem and there are no implementation surprises. In a scenario like that, writing code to directly solve their problem is a feasible approach. But that will most definitely not happen any time soon, if ever. So in the mean time, we are stuck dealing with implementation details that fall outside the scope of the business problem.
When programmers write code, they have two tightly-coupled problems. There is the problem of making the software do what it was intended to do, the business problem. There is also the problem of the the other, unforeseen implementation details, the implementation problem. When we begin to write code for the business problem, the implementation problem doesn't really exist yet. How can it? These are unanticipated problems. They don't come into being until you can see them. This makes sense to a certain extent because if you start thinking about potential implementation problems too much before some design activities have started, no code would ever be written.
So what is the real benefit to separating these two problems, if any? It doesn't seem very obvious what the exact benefit of separating the business problem from the implementation details is at first. But one problem with not doing so is apparent. Since implementation detail problems do not really exist until the code is being written, they often affect the business problem implementation once they come about. That is, if a programmer spends time designing some ideal code for the business problem, depending on how specific that design is, an implementation detail problem could put the whole design in jeopardy.
Since code is so tightly coupled with the implementation of a running system, a good way to represent the business problem is with a model. A model is not part of the running system but it is an artifact of the process used to create the running system. UML models are a good way to represent any given software system. They can show almost any level of detail one might be interested in seeing. There is, however, a similar problem with models. You have the ability to start getting into implementation details.
This goes to show that modeling your code before actually writing it isn't a magic way to fix your code design. The common problem with creating models is that they tend to evolve too quickly without writing any code. If the level of specificity in your model gets too high, you've not only taken a waterfall approach but you're also taking a risky path by assuming there will not be any seemingly small implementation issues. Models are a good way to start off the business domain model as long as they are general enough. The level of specificity cannot be too high before code is written. Even then, it doesn't need to delve into too much detail just for the sake of it. Model details are better left out until they become a requirement.
Now lets take a step back and think about this for a moment. We now have a business problem that we're going to solve with software. In order to build this software, we need to write code that will implement the solution to the business problem. We know that there are going to be changes because our computing environments are disparate enough that we has humans cannot predict exactly how our code will behave. In order to help distance our business problem from any potential implementation problems, we build a high-level model of the business problem.
We should now be all set to start coding and hope for the best, right? Starting to code is definitely the right answer. Hoping for the best suggests an uncontrolled level of uncertainty. This can be at least somewhat controlled by expecting unexpected implementation details. Remember that your code and your model will always change throughout iterations of the project. The model you build will also have some overlap with the implementation. This is necessary unless the stakeholders are only expecting a model of the software and not the software itself.
Once these implementation detail issues do exist, is it worth modeling these issues? Only if it is separated from the business problem within the model somehow. It might even make more sense to create a completely separate model for implementation details. But only if it adds value. Modeling the nuances of implementing software isn't an exact science because chances are, these same details will become irrelevant in five years.
To sum this all up, remember that there is value in upfront code design centered around the business problem at hand. This doesn't necessarily mean modeling, it could be as straightforward as prototyping a command line interface simply for the purpose of testing how well the abstractions in your domain work. Modeling does offer a visual design aspect that often cannot be gleaned from code itself.
Labels:
code
,
design
,
modeling
,
programming
,
uml
Thursday, April 15, 2010
Programming Sprints
Here is an interesting question, how many hours in a given week can you program? If you've got your head down and the code is just flowing out nicely, it isn't difficult to be very productive for hours at a time. But these sprints come in bursts. This code inspiration needs to come from somewhere. That is the other part of programming that isn't viewed as productivity. I'd say at least half, if not more, of a programmers time is devoted to reading. Either other code, a specific technology, technology in general, or something completely unrelated. Code sprints are spawned from doing this, not perpetually writing code.
Labels:
code
,
development
,
programming
,
reading
,
sprint
Wednesday, April 7, 2010
Language Popularity
According to the TIOBE index, the C programming language is back at number one for popularity. This comes as no big surprise as the language has thrived for decades due to it's simplicity. Also, according to the index, Python and Javascript are down. This seems strange since these two languages are huge in the web application space.
Labels:
c
,
javascript
,
popular
,
programming
,
python
,
tiobe
Tuesday, April 6, 2010
Optimizing For Readability
How does one measure the readability of a given piece of code? What makes this especially challenging is that developers all have their own unique preferences and style when it comes to reading and writing source code. But readability isn't necessarily the same thing as coding style. Readability should trump style preference.
There are certain aspects of code that make it readable. For instance, meaningful variable names aren't that hard to come up with and make a world of difference when someone else needs to read your code. Adding some space rather than cramming constructs together will always increase readability. At the same time, however, conciseness is always a readability enhancement.
Simple things add up in the long run. There are only larger structural pieces of code that affect code readability. For instance, the location of a class, the modularity affects the difficulty of locating things. These are larger concepts that are more closely related to style than readability. Readability in this context refers to what the developer can see on the screen at any given time.
There are certain aspects of code that make it readable. For instance, meaningful variable names aren't that hard to come up with and make a world of difference when someone else needs to read your code. Adding some space rather than cramming constructs together will always increase readability. At the same time, however, conciseness is always a readability enhancement.
Simple things add up in the long run. There are only larger structural pieces of code that affect code readability. For instance, the location of a class, the modularity affects the difficulty of locating things. These are larger concepts that are more closely related to style than readability. Readability in this context refers to what the developer can see on the screen at any given time.
Labels:
code
,
development
,
programming
,
readability
,
style
Monday, March 8, 2010
Programming Skill
It is amazing how many people apply for programming positions who simply can't do it. But it also sounds like people are getting hired. It begs the question, how soon are these people that are clearly out of their field given a programming task after they're hired?
This actually reminds me of school. Computer Programmer sounded like an attractive field to be in but once it came time to write something functional, many people just had blanks looks on their face. I don't think they were around the following semester.
This actually reminds me of school. Computer Programmer sounded like an attractive field to be in but once it came time to write something functional, many people just had blanks looks on their face. I don't think they were around the following semester.
Labels:
cantdoit
,
education
,
field
,
programming
,
school
Friday, February 26, 2010
Learning Python
Several years ago, the second edition of Learning Python was one of my first exposures to the Python programming language. Now the fourth edition of the book is available and is getting good reviews.
The latest edition has Python 3 reference material and takes the approach of inserting Python 3 content where necessary. I think that this is a good approach rather than treating the two languages as completely separate entities. Just because the two versions of the language aren't compatible with one another doesn't mean they are really that different.
If the fourth edition of the book is anything like what I remember from the second edition, I highly recommend it for anyone looking to learn the language.
The latest edition has Python 3 reference material and takes the approach of inserting Python 3 content where necessary. I think that this is a good approach rather than treating the two languages as completely separate entities. Just because the two versions of the language aren't compatible with one another doesn't mean they are really that different.
If the fourth edition of the book is anything like what I remember from the second edition, I highly recommend it for anyone looking to learn the language.
Labels:
book
,
language
,
learning
,
programming
,
python
Thursday, December 17, 2009
Music At Work
This slashdot entry contains some very anger-inspiring content. Especially if you are a developer. Even more especially if you are a developer that listens to music while you work, which I would think most do. The obvious exceptions are the ones who work for the lunatic boss mentioned in the entry who came up with the brilliant policy of banning music at work for developers.
Personally, I would be devastated if I had no music to listen to while writing code. Forget about blocking out office noise. What about the rhythmic productivity music adds to the though process? Is that of no value? I sometimes here a song and almost instantly, I can visualize the code I was writing while listening to it years ago. I wonder if that means the music was distracting me while I was writing it.
Don't take away the right to listen to music at work where it isn't necessary. People just resent you for it and you aren't helping anyone by doing it. You may think you are helping your ego, but all you're really doing is giving yourself false hope as a leader.
Personally, I would be devastated if I had no music to listen to while writing code. Forget about blocking out office noise. What about the rhythmic productivity music adds to the though process? Is that of no value? I sometimes here a song and almost instantly, I can visualize the code I was writing while listening to it years ago. I wonder if that means the music was distracting me while I was writing it.
Don't take away the right to listen to music at work where it isn't necessary. People just resent you for it and you aren't helping anyone by doing it. You may think you are helping your ego, but all you're really doing is giving yourself false hope as a leader.
Labels:
idiot
,
music
,
musicatwork
,
productivity
,
programming
Thursday, November 26, 2009
Developer Education
This entry asks what type of developer you are. White collar versus blue collar. What the question essentially comes down to is what level of education do you have. White collar developers are considered to have a four-year college or university degree while the blue collar developers have less education. So, are these degrees really necessary to become a software developer?
This question really needs to be in a less broad context. For instance, is it likely that as a developer you will need an advanced computer science degree to build typical web applications? Not likely. Will you need one to do optimization work with embedded software. Probably.
Computer scientists have the theoretical know-how that is an absolute must in certain circumstances. Other developers have more experience in what is the more practical way out of a given situation. The important thing to note, I think, is that either one has limitations. It is the job at hand that dictates who is best for the job.
In addition, not being able to produce a degree for highly niche jobs doesn't necessarily mean a road block for some developers. If you can show, through software that you have built in the past, the knowledge you have, it is a good alternative.
This question really needs to be in a less broad context. For instance, is it likely that as a developer you will need an advanced computer science degree to build typical web applications? Not likely. Will you need one to do optimization work with embedded software. Probably.
Computer scientists have the theoretical know-how that is an absolute must in certain circumstances. Other developers have more experience in what is the more practical way out of a given situation. The important thing to note, I think, is that either one has limitations. It is the job at hand that dictates who is best for the job.
In addition, not being able to produce a degree for highly niche jobs doesn't necessarily mean a road block for some developers. If you can show, through software that you have built in the past, the knowledge you have, it is a good alternative.
Monday, October 5, 2009
Statically Typed Languages
Any programming language in existence today has primitive types that values can be defined as. An example of this would be an integer or a string. This holds true for both statically typed languages and dynamically typed languages. The differences between the two programming language varieties is that in statically typed languages, variables require at least a primitive type before they may be assigned a value. That is, you can't say that variable int_obj has a value of 10 before declaring that int_obj is going to store integer values. Additionally, once a variable has been declared to store certain types, it cannot store a different type. So our int_obj cannot decide to store "10".
The reason for doing this is so that the program can be compiled into machine code that is directly executable by the hardware. Otherwise, the it only serves as a limitation. So are statically typed languages dead? This obviously depends on context because the raw machine code performance is always going to be a requirement. But does this been that entire applications need to be built using a statically typed languages such as C? Probably not. Developing in these languages is no easy task and there are several other development factors to consider during development such as maintainability. Dynamically typed languages offer much more flexibility in both design and maintainability. But this comes at the cost of performance because dynamically typed languages need a virtual machine to execute programs.
Java is an interesting language because it was designed to help implement C++ style applications without the added complexity. Java, however, is still considered a statically typed language. Developers still need to declare the type of the construct before it is used. Java still does perform well, but it is still an interpreted language that is statically typed. This actually helps with the performance even though it is an interpreted language.
So is it possible to have a dynamically typed language that can still support the raw performance offered by statically typed languages? The best approach here is to have a dynamically typed languages which are extended by the low level constructs of statically typed languages.
The reason for doing this is so that the program can be compiled into machine code that is directly executable by the hardware. Otherwise, the it only serves as a limitation. So are statically typed languages dead? This obviously depends on context because the raw machine code performance is always going to be a requirement. But does this been that entire applications need to be built using a statically typed languages such as C? Probably not. Developing in these languages is no easy task and there are several other development factors to consider during development such as maintainability. Dynamically typed languages offer much more flexibility in both design and maintainability. But this comes at the cost of performance because dynamically typed languages need a virtual machine to execute programs.
Java is an interesting language because it was designed to help implement C++ style applications without the added complexity. Java, however, is still considered a statically typed language. Developers still need to declare the type of the construct before it is used. Java still does perform well, but it is still an interpreted language that is statically typed. This actually helps with the performance even though it is an interpreted language.
So is it possible to have a dynamically typed language that can still support the raw performance offered by statically typed languages? The best approach here is to have a dynamically typed languages which are extended by the low level constructs of statically typed languages.
Tuesday, July 14, 2009
Three Languages For Learning How To Develop Software
In an interesting discussion, the question of which programming language is best suited for teaching computer science students is raised. It is an interesting question because it seems that there isn't any real consensus among schools as to what the standard language should be. This brings up another question; should there be a standard language that should be taught to computer science students? Or should a more adaptive approach be taken and teach a language geared more toward some specialization?
I think the introductory-level courses need at least some level of language standardization amongst schools. Later on in the computer science program, if there is a specialization the student is interested in, the language best suited for that purpose should be taught. However, there are countless specializations a computer science graduate could strive to be an expert in. I don't think it is possible to realize them all, but the schools that teach these computer science programs should at least open a few broad categories of computer science specializations rather than just a single end point.
During the introductory courses of a computer science program, the concepts take the top priority. I think three languages could serve as a powerful tool in teaching these concepts. First, the C programming language. C allows for a good introduction to low-level programming concepts. It is also a good example of language design and is still heavily used in the industry. Second, the C++ programming language. C++ is a natural progression from C in order to introduce object-oriented concepts. Still heavily used in industry and still low-level. Lastly, the Python programming language. Python gives a good introduction to high-level languages. Not as heavily used in industry but is always gaining popularity. Python and C are highly interoperable.
I think the introductory-level courses need at least some level of language standardization amongst schools. Later on in the computer science program, if there is a specialization the student is interested in, the language best suited for that purpose should be taught. However, there are countless specializations a computer science graduate could strive to be an expert in. I don't think it is possible to realize them all, but the schools that teach these computer science programs should at least open a few broad categories of computer science specializations rather than just a single end point.
During the introductory courses of a computer science program, the concepts take the top priority. I think three languages could serve as a powerful tool in teaching these concepts. First, the C programming language. C allows for a good introduction to low-level programming concepts. It is also a good example of language design and is still heavily used in the industry. Second, the C++ programming language. C++ is a natural progression from C in order to introduce object-oriented concepts. Still heavily used in industry and still low-level. Lastly, the Python programming language. Python gives a good introduction to high-level languages. Not as heavily used in industry but is always gaining popularity. Python and C are highly interoperable.
Thursday, June 11, 2009
Fortran And Physics
An interesting entry got me thinking about hard science and low-level programming languages such as C and Fortran. Do the two fields really mesh well together? As the entry suggests, they do not. Initially, back when Fortran was in it's prime, it would make sense for Physicists to use a language such as Fortran to compute astonishingly complex mathematics very fast. But back then, there really any alternative. This clearly isn't the case today.
It seems that undergraduates in the hard sciences are still taught the Fortran programming language in an introductory programming course. Computer science students are also taught Fortran. I think the latter may make sense and the former not so much. In the end, it really comes down to how the student will benefit in the future. At least in the world of academia.
For computer science students to have a thorough understanding of low-level programming concepts is beneficial. And, there is only one way this insight is gained. Through the painstaking process of learning a language such as Fortran inside and out.
Physicists, however, may not share the same benefit as would computer scientists years after having learned such a language. I think this makes sense. Why would physicists want to concern themselves with low-level software details when the low-level math problem at hand is probably much more interesting to them. Would a software developer be overly pleased to hear that he has to write a web browser from scratch in order to build a web application? Not likely.
I think that programming languages are sophisticated enough these days to allow for the scientists in other fields to focus on what matters to them. Leave the low-level software to the computer scientists. Languages such as Python are there for physicists to use as a result of computer scientists taking care of the low-level details. All parties are much happier in this scenario.
It seems that undergraduates in the hard sciences are still taught the Fortran programming language in an introductory programming course. Computer science students are also taught Fortran. I think the latter may make sense and the former not so much. In the end, it really comes down to how the student will benefit in the future. At least in the world of academia.
For computer science students to have a thorough understanding of low-level programming concepts is beneficial. And, there is only one way this insight is gained. Through the painstaking process of learning a language such as Fortran inside and out.
Physicists, however, may not share the same benefit as would computer scientists years after having learned such a language. I think this makes sense. Why would physicists want to concern themselves with low-level software details when the low-level math problem at hand is probably much more interesting to them. Would a software developer be overly pleased to hear that he has to write a web browser from scratch in order to build a web application? Not likely.
I think that programming languages are sophisticated enough these days to allow for the scientists in other fields to focus on what matters to them. Leave the low-level software to the computer scientists. Languages such as Python are there for physicists to use as a result of computer scientists taking care of the low-level details. All parties are much happier in this scenario.
Sunday, May 31, 2009
Think Again About Promoting Your Language
Are you one to promote your programming language of choice? I know I am. This entry may in fact force anyone who promotes a given language and is not thoroughly in touch with the technical realities to reconsider what they are promoting. Lots of interesting data found here and and a very worth-while read.
Wednesday, January 28, 2009
C remains popular while Python is still low-key.
An interesting entry cites the C programming language as the most popular choice for new open source projects. There are also some other languages that followed C as popular choices. Python wasn't one of them.
So what does this mean? Absolutely nothing. It means that there are several existing and successful Python projects out there. Although I'm not a huge fan of some of the other languages mentioned, as a Python developer, I do like C. Python and C interoperability at the system level isn't too difficult to achieve.
Of course, this isn't a requirement. Ideally, if some new killer open source application written in C is made available, you can make bindings between it and your Python application.
So what does this mean? Absolutely nothing. It means that there are several existing and successful Python projects out there. Although I'm not a huge fan of some of the other languages mentioned, as a Python developer, I do like C. Python and C interoperability at the system level isn't too difficult to achieve.
Of course, this isn't a requirement. Ideally, if some new killer open source application written in C is made available, you can make bindings between it and your Python application.
Labels:
c
,
language
,
opensource
,
opinion
,
programming
,
python
Subscribe to:
Posts
(
Atom
)