|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On August 16 2015 18:32 Manit0u wrote:
1. The most important thing in Git is performance. You can't really trump C in that matter. Another poster addressed this point already. C and C++ are both very fast, and either can be made slower than the other through design decisions.
2. C is much less forgiving than C++, which leads to tighter code reviews and requiring more competence on the developer's side. It's also much simpler, making it easier to debug. Templates in C++ are difficult to debug, but extensive template metaprogramming can be a code smell and usually should be avoided, and is impossible to emulate with C. Sure, there are a few more subtleties in C++ that the uninitiated will miss, but C has it's own share of difficult to diagnose problems too. Whilst C is less complex as a language, the codebase needs to be more complex to work around the limitations in the language. Hacking around with pointers and little abstraction leads to lovely memory access problems to debug throughout the program. I also fail to see how requiring more competence is a positive feature in a language.
3. The biggest gripe Linus has with C++ is the fact that the language offers too much freedom to the programmer (think opposite of Python, where there's only one best way to do something). This in turn makes for huge code discrepancies between programmers (even within C++ libraries you have some math stuff that's inconsistent and incompatible with each other, like matrices), which can be a nightmare to review and debug in an open source project with many contributors. I disagree with your assertion here. The biggest gripe he seems to have is that C++ programmers seem to be less experienced in general, and don't know what they're doing/tend to think at a higher level. Which is possibly a bad thing for his project, but not a reflection on the language at all.
I think C has it's place, in the embedded systems environment primarily, where writing a fully compliant C++ compiler for every platform is a waste of effort. I can't speak for kernel/OS development because I've never done it. Having good coding standards for (a subset of) C++ will give you far better abstraction and performance mostly equivalent writing plain C (yes there are some slower bits you can choose to use), without requiring a decade of experience (for esoteric C++ features).
C++ for non-performance oriented code is a good way to waste developer time though.
|
Zurich15361 Posts
On August 16 2015 07:23 sabas123 wrote:Show nested quote +On August 16 2015 06:37 Sufficiency wrote:
A small digression:
I have been using Python on and off for half a year now. I don't claim to be an expert by any means (in fact I still struggle with list comprehension and need to rely on Google's help), but I just want to say that writing code in Python has been a truly enjoyable process for me.
This comes from someone who started out with C++ at an early age. Can you tell me why python is so awesome? I personally only have touched the c family of c/c++, php and c#.
Because within the first day you will find that you can write code as fast as you can type.
Seriously, if you have used PHP before, for you next web project try Python with a mini framework like Flask or Bottle. It's night and day. You'll get your shit done faster guaranteed and it'll include learning the language.
Oh, and yeah, use Python 3.
|
Oh boy. What a fun day I've had at work.
Starts off as usual, client wants some new feature in his system. Something that would be relatively simple to accomplish (add file uploads to the static pages) if not for the fact that when this client approached us first the management took the decision to use 3rd party tools instead of using our own system as base for this one. Here comes me, being assigned to this task which was estimated at 1h (hahaha).
Checking out the system revealed a couple of facts:
1) Symfony2 (good so far)
2) Sylius (would be good if it wouldn't be in the 0.15 beta stage or something)
3) Symfony CMF + Sonata Blocks for static content (I had some dealings with this before, wasn't good experience)
Checking out things that were already done reveals a relatively simple process of implementing the feature. Create new static block type (for holding a file), then container for them (a bit like image slideshow, something that would allow people to add multiple files as a single section instead of doing it one by one) and it's done as the client would then be able to add either single files or collections wherever they want in the static content.
Now the fun starts...
As I quickly discover, there's plenty of overrides already in the system (including Sylius overriding their own product model, WTF?), there's hundreds of lines of configuration code accompanying it (enterprise software, yay!) which I don't really want to delve into.
If anyone has ever seen anything like that, you know what I mean:
namespace Acme\SocialBundle\DependencyInjection;
use Symfony\Component\Config\Definition\Builder\TreeBuilder;
use Symfony\Component\Config\Definition\ConfigurationInterface;
class Configuration implements ConfigurationInterface
{
public function getConfigTreeBuilder()
{
$treeBuilder = new TreeBuilder();
$rootNode = $treeBuilder->root('acme_social');
$rootNode
->children()
->arrayNode('twitter')
->children()
->integerNode('client_id')->end()
->scalarNode('client_secret')->end()
->end()
->end() // twitter
->end()
;
return $treeBuilder;
}
}
Instead I opt for a nicer way of doing it, creating my own bundle with separate configuration so I can keep everything contained, decoupled and nicely organized. I do all the dependency injection, extend a few things to keep it compatible with the rest of the system, follow the docs etc. All is cool and dandy until I hit a brick wall...
Everything looks picture perfect, neat and all, but I keep getting errors about the system not being able to resolve the namespace for one of the files. I'm dumbfounded. I double check the files and config to see if perhaps I've misspelled something, put wrong routes or anything like that. Nope, all looks good.
The problem:
All those bundles (symfony, symfony-cmf, sylius) use different ways of automatic namespace resolution. Sylius is broken down into bundles and components (model files reside in the components while controllers, views and config are kept in the bundle, model namespaces usually look something like that: Sylius\Component\Model\Product), symfony has its standard way of storing models in the Entity folder (YourBundle\Entity) while symfony-cmf keeps it either in CmfBundle\Model for regulard db stuff or CmfBundle\Doctrine\Phpcr for content blocks.
Since the system is technically Sylius I first try to check where they keep their content blocks. I discover that they do have static content, but they simply use their own controllers and repositories for that while leaving all the model files in the symfony-cmf stuff (not cool). My head starts spinning at this point. I'm trying various things, playing around with configuration etc. etc.
Took me 10 hours to discover that if you want to create your own block type using symfony-cmf you can't follow their project structure. You have to keep your block files in the frigging \Document directory (which is obviously inconsistent with all of the above), otherwise your namespace won't be resolved. Discovering where to put the mapping config files was another headache since I've had multiple options there too.
And that, ladies and gentlemen, is why convention beats configuration.
|
On August 20 2015 19:06 zatic wrote:
Oh, and yeah, use Python 3.
Good call. I still see a lot of people use Python 2. Given that it is being deprecated within the next 5 years, 3 is the way to go.
But really, as zatic said, try python out and you'll get almost immediately why people like it. You can do so much with so little code. I built an entire search simulation for my AI class in Python (using the NetworkX package. Seriously, if you need to to graph stuff, NetworkX is AMAZING) in under 600 lines, when others using C#, C++, and Java were using at least 2 or 3 times as many lines. And I can guarantee my version was easier to read and figure out.
|
On August 25 2015 07:42 Ben... wrote:Good call. I still see a lot of people use Python 2. Given that it is being deprecated within the next 5 years, 3 is the way to go. But really, as zatic said, try python out and you'll get almost immediately why people like it. You can do so much with so little code. I built an entire search simulation for my AI class in Python (using the NetworkX package. Seriously, if you need to to graph stuff, NetworkX is AMAZING) in under 600 lines, when others using C#, C++, and Java were using at least 2 or 3 times as many lines. And I can guarantee my version was easier to read and figure out.
It's being deprecated in the next 5 years... that's not the most convincing argument I have heard :'D
But seriously, it really depends on what you want to do and what libraries you need for that. I use Python 2.7 because there are quite a few ML and other scientific libraries that are not available (yet? ever? who knows. the perils of community development projects) for Python 3. Rather than fussing about whether my library is available in Python 3, I just use Python 2.7 for everything. And yes, that means I sometimes run into stupid issues that have already been fixed in newer versions (although never without either a fix or a workaround for 2.7), but while 2.7 development is no longer ongoing, it is really stable.
|
Zurich15361 Posts
For someone just wanting to try out Python python3 is the way to go though. python2 still has much inconsistency in there.
Heck, print('Hello World') instead of print u'Hello World' says it all really.
Libraries are a bit annoying right now that's true. I am expecting that to reverse soon though, there will be plenty of libraries that will continue only on the 3 branch.
|
While speaking of python, can someone help me out with pyplot? I have a loop that returns me a matrix and I want to visualize that matrix with pyplot so I made a function that does this.
The problem is that I just can't manage to get the window to close again, plt.close() simply isn't working. I have already used plt.ion() so it is supposed to stay interactive, but close() just doesn't work.
|
On August 26 2015 04:10 Nyxisto wrote:
While speaking of python, can someone help me out with pyplot? I have a loop that returns me a matrix and I want to visualize that matrix with pyplot so I made a function that does this.
The problem is that I just can't manage to get the window to close again, plt.close() simply isn't working. I have already used plt.ion() so it is supposed to stay interactive, but close() just doesn't work.
You want to close it upon what? You can close a pyplot window by clicking on the X in the top right corner. If you want to use your window in some bigger program, you should probably look into drawing it on a canvas and using the canvas.
Anyway, make sure you have plt.ion() before plt.show() (otherwise it's pointless). Then plt.close() should close your current plot, or use plt.close('all') to close all plots. However, it is still not completely clear to me why you would want to close pyplot's window from your python script.
EDIT: ran a test with python 2.7.6 and matplotlib 1.3.1 in Linux (Ubuntu with Xfce4 desktop environment) and it works just fine.
|
I fixed it now. I just didn't import all the stuff from pylab that I needed.
|
I'm not seing Go mentioned (golang if you wanna search it). It's got the stability of java without all the class hierarchy / access controls: you manage your abstractions purely with interfaces. That might scare you a bit, unless you're a C programmer, but trust me it's refreshing. It borrows a lot from C for language design, for example pointers, including pointers to functions so you can make closures and stuff. However it does even better, because pointers do not require explicit indirection for accessing fields (no ptr->fieldA, just ptr.fieldA). It's got dirt simple dependency management: you can literally just plop a github url in your import block. It has a great concurrency model, with something called channels, basically message passing for threads. The design is conducive to multicore systems, and as we all know parallelism is the future.
The native toolset is also pretty amazing. They have something called gofix which lets you write refactoring SCRIPTS. walking the parse tree of a program, and rewriting as you go. So if you have a lib that you released 1.0 for, and your ready for 2.0 but your users aren't, instead of promising to maintain 1.0, you just hand out a refactor script, and they run that on their codebase, so they're always up to date. And some other random stuff ... You can run your programs with "-race" flag to help find race conditions. gofmt can canonicalize all your code before committing. The static analysis available to you here is unrivaled.
My only gripes so far have been the 1) uncomfortably lax namespacing: there's no "file" scope, just package scope and function scope which leads me to 2) packages are not like java packages where they are actually folders: a package is your whole fucking project, and your whole fucking project has gotta go in one fucking folder, maybe they are telling me to break my project into libs idk. 3) A stupid stupid rule where unused variables and imports are errors not warnings, more specifically the Go team does not believe in warnings. If you look in the doc to find out how to bypass this, they tell you this painful way that's more annoying than just commenting the import. They're basically just like "fuck you, remove your import", paraphrased of course. 4) No immutability. God I miss my immutable guava classes. They've got a const, but you can't make struct fields const like you can make class attributes final in java. This however, is fairly well managed because pointers let you essentially decide whether to pass something by value or reference, thereby conferring read-only access to an object as desired. And the lightweight structs make copying / passing by value inexpensive 5) arrays and slices were a bit confusing, or I'm an idiot, or I couldn't think of an obligatory number 5, whichever you prefer.
So yeah it's pretty hot right now. Y'all should check it out.
|
On August 25 2015 07:42 Ben... wrote:Good call. I still see a lot of people use Python 2. Given that it is being deprecated within the next 5 years, 3 is the way to go. But really, as zatic said, try python out and you'll get almost immediately why people like it. You can do so much with so little code. I built an entire search simulation for my AI class in Python (using the NetworkX package. Seriously, if you need to to graph stuff, NetworkX is AMAZING) in under 600 lines, when others using C#, C++, and Java were using at least 2 or 3 times as many lines. And I can guarantee my version was easier to read and figure out.
Almost every language can be readable if one has good discipline, that is, good naming of variables, short methods with good names, etc.
|
|
|
In my opinion, if you let the project source files grow to 15GB it's not really the vcs you should be worried about. And even then you could simply use submodules and such to split it into managable chunks.
We did that in our company, split our projects into versioned modules so we can use only the parts we need. Mixing and matching various versions is also easy this way.
|
On August 27 2015 18:01 Manit0u wrote:In my opinion, if you let the project source files grow to 15GB it's not really the vcs you should be worried about. And even then you could simply use submodules and such to split it into managable chunks. We did that in our company, split our projects into versioned modules so we can use only the parts we need. Mixing and matching various versions is also easy this way.
I don't know how fast of a version control does facebook expect to have. My company has 3-4GBs of repositories and has a whole lot of them (each repo of my current project is 4GB divided into submodules and has 4 repos of them) and number of commits may reach to 4 figures per day and SVN doesn't even flinch in terms of performance. Even for git, which keeps commit history locally, I don't think it would be so slow that it is noticable. I don't have git vs svn performance benchmarks but one really highly skilled dude in my company told that git has zero downsides in comparison to svn.
|
On August 28 2015 00:03 Djagulingu wrote:Show nested quote +On August 27 2015 18:01 Manit0u wrote:In my opinion, if you let the project source files grow to 15GB it's not really the vcs you should be worried about. And even then you could simply use submodules and such to split it into managable chunks. We did that in our company, split our projects into versioned modules so we can use only the parts we need. Mixing and matching various versions is also easy this way. I don't know how fast of a version control does facebook expect to have. My company has 3-4GBs of repositories and has a whole lot of them (each repo of my current project is 4GB divided into submodules and has 4 repos of them) and number of commits may reach to 4 figures per day and SVN doesn't even flinch in terms of performance. Even for git, which keeps commit history locally, I don't think it would be so slow that it is noticable. I don't have git vs svn performance benchmarks but one really highly skilled dude in my company told that git has zero downsides in comparison to svn.
Given that one of the advantages of GIT over SVN is performance, I don't see why you'd expect it to be slower. Commits in git are lightning fast, and pushes *should* be faster than an SVN commit of a similar size and complexity.
|
On August 28 2015 00:09 Acrofales wrote:Show nested quote +On August 28 2015 00:03 Djagulingu wrote:On August 27 2015 18:01 Manit0u wrote:In my opinion, if you let the project source files grow to 15GB it's not really the vcs you should be worried about. And even then you could simply use submodules and such to split it into managable chunks. We did that in our company, split our projects into versioned modules so we can use only the parts we need. Mixing and matching various versions is also easy this way. I don't know how fast of a version control does facebook expect to have. My company has 3-4GBs of repositories and has a whole lot of them (each repo of my current project is 4GB divided into submodules and has 4 repos of them) and number of commits may reach to 4 figures per day and SVN doesn't even flinch in terms of performance. Even for git, which keeps commit history locally, I don't think it would be so slow that it is noticable. I don't have git vs svn performance benchmarks but one really highly skilled dude in my company told that git has zero downsides in comparison to svn. Given that one of the advantages of GIT over SVN is performance, I don't see why you'd expect it to be slower. Commits in git are lightning fast, and pushes *should* be faster than an SVN commit of a similar size and complexity.
Git actually IS faster than SVN? Damn, it does have zero downsides in comparison.
|
I've got an Android phone today. What options do I have for a private, personal app? Is it Java mainly? I know that language, but I'm going to google if C/C++ is also an option. 
Edit: Haha, it's like they wrote this for me.
Android NDK
The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++. Typically, good use cases for the NDK are CPU-intensive applications such as game engines, signal processing, and physics simulation.
Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
|
On August 27 2015 18:01 Manit0u wrote:In my opinion, if you let the project source files grow to 15GB it's not really the vcs you should be worried about. And even then you could simply use submodules and such to split it into managable chunks. We did that in our company, split our projects into versioned modules so we can use only the parts we need. Mixing and matching various versions is also easy this way.
That is one route. Facebook, Google, etc chose to have single repository, you can read about the tradeoffs in the second link. Or here: http://www.infoq.com/presentations/Development-at-Google
Neither git nor svn (nor native mercurial) is fast enough to work at this scale. Perforce is, sort of... until it isn't.
|
On August 28 2015 07:27 darkness wrote:I've got an Android phone today. What options do I have for a private, personal app? Is it Java mainly? I know that language, but I'm going to google if C/C++ is also an option. Edit: Haha, it's like they wrote this for me. Show nested quote +
Android NDK
The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++. Typically, good use cases for the NDK are CPU-intensive applications such as game engines, signal processing, and physics simulation.
Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need.
Unless you really want to:
1) Write something that does very heavy computing
2) Use a specific library only available in C/C++
or
3) Have a particular fetish for needlessly complex programs
You should write Android apps in Java. An app can never be purely C/C++, because there is no I/O access through the NDK. That means any input and output has to be done in the Android framework in any case.
|
An app can never be purely C/C++, because there is no I/O access through the NDK. That means any input and output has to be done in the Android framework in any case.
How is that even possible? At the very least you must be able to call the syscalls directly if there is no C library wrapping them.
|
|
|
|
|
|
EPT
