Everything all on one page, a few scattershot examples, with some inline with the documentation and others not. It's up to you to figure out what type the parameters should be and their valid ranges. Though the naming is usually such that if you read the entire page, the information is there, somewhere. As documentation goes, it's pretty good. The information is there, and it's correct.
The API documents have everything you need for a reference, are correct, tell you expected behavior (not threadsafe), sequencing considerations, and detailed information on what each method does. The perfect thing if you know what you want and how to use it, but need a refresher on an API you haven't used in awhile/used before.
The tutorial is fantastic for a new learner since it sets up everything you're expected to know and then walks you through how to use it.
IMO it beats MS's documentation by a country mile.
https://docs.python.org/3.4/library/datetime.html is one I'm always stuck on. That page looks like they barfed up a bunch of information into HTML and slapped some bold/italics tags everywhere and figured everyone can just sift through it to figure it out.
Everything all on one page, a few scattershot examples, with some inline with the documentation and others not. It's up to you to figure out what type the parameters should be and their valid ranges. Though the naming is usually such that if you read the entire page, the information is there, somewhere. As documentation goes, it's pretty good. The information is there, and it's correct.
The API documents have everything you need for a reference, are correct, tell you expected behavior (not threadsafe), sequencing considerations, and detailed information on what each method does. The perfect thing if you know what you want and how to use it, but need a refresher on an API you haven't used in awhile/used before.
The tutorial is fantastic for a new learner since it sets up everything you're expected to know and then walks you through how to use it.
IMO it beats MS's documentation by a country mile.
https://docs.python.org/3.4/library/datetime.html is one I'm always stuck on. That page looks like they barfed up a bunch of information into HTML and slapped some bold/italics tags everywhere and figured everyone can just sift through it to figure it out.
Interesting. I see what you're saying, I guess. But really, the complaints are around the choice of formatting of the information and that the tooling gives you the option of doing it kind of shitty and cluttered, then?
If you use docstrings and Sphinx' docstring parsing, you get the stuff like https://python-docdown.readthedocs.io/en/latest/docdown.html#module-docdown.docdown which is about like using javadoc. The other things you are complaining about, I'd bet, are basically hand built HTML (or really hand built RST converted to HTML). So the tooling exists to do exactly what you guys would like, but I can see the argument that the dev community does not exactly encourage it and instead tends towards a bit more of a mess.
I'd actually love to hear your thoughts on documentation such as found here https://smartdevicelink.com/en/docs/iOS/master/ and the other docs there. The documentation generating platform was built by my employer. It uses markdown, some markdown extensions which we/the client open sourced, and can be built from markdown docs on github and inline doc stuff from javadoc, doxygen, and jazzy. I believe there are hopes to open source all of it, but I'm not sure exactly when or how it will be broken up as there are certainly parts of this platform which are project/implementation specific.
Loaded question: How is it being a Java developer - one of the options available to me is to retrain into a development role. Just curious about it.
The easy answer is "terrible", I'm not sure any of us truly like Java. Really, though, the overall work environment will matter FAR more than the language. I find java tedious and overly verbose in most cases, but once you're working with something 8 hrs/day and aren't restricted to core libs by school, then that is probably the least of your concerns.
Loaded question: How is it being a Java developer - one of the options available to me is to retrain into a development role. Just curious about it.
I used Java when I was in school, but haven't used it professionally. I have used C++ and Python professionally in an embedded environment for the past 4 or so years. So de-rate the following appropriately.
Excellent documentation, good library support (but not as easy to install and use as say, Python's massive library where I can pip install a package and be up and running in five minutes), generally easy to use with some significant warts.
Good: reflection is handy, and the type safety means there are vast classes of errors that'll be caught at compile time instead of runtime (my biggest complaint about Python. Duck-typing is great for quick and dirty hacks, but maintenance requires vast testing infrastructure to make sure you didn't accidentally pass in a type that will work for the every-day use-case, but will blow up for the rarely-taken execution path). Lambdas, try-with-multicatch, try-with-resources, a generics system that isn't turing complete, a not-completely-insane package system are all helpful.
Biggest warts I ran into were things like const-correctness (Java doesn't make it easy to do, or even possible for things like arrays), compile time computation (not available), exception specifications (they tend to infect everything), finalizers instead of destructors (can't do RAII), and no first-class functions (but at least now it's possible to pass methods, woo!). Another issue is the massive object-oriented-bullshit infrastructure many projects seem to have picked up while using Java. That's not a complaint about the language, but instead about the language community. And of course everything requires at minimum a class, but that can end up simply being a namespace for your functions, so I don't see that as a big deal.
Oh my, I just found something out. You guys remember those 100 or so lawyers that descended on airports in NYC and Washington D.C. a few weeks ago to represent people affected by Trump's executive order?
Those were people from my company, using a system that I built to organize.
Loaded question: How is it being a Java developer - one of the options available to me is to retrain into a development role. Just curious about it.
The easy answer is "terrible", I'm not sure any of us truly like Java. Really, though, the overall work environment will matter FAR more than the language. I find java tedious and overly verbose in most cases, but once you're working with something 8 hrs/day and aren't restricted to core libs by school, then that is probably the least of your concerns.
Academic here, not professional. I like Java fine. Ultimately, I'm pretty language-agnostic. I like Java as much as C++ or C# or Python, as languages. They have their respective pros and cons, and people have different preferences, and a lot of these preferences are culturally driven as backlashes against whatever was the most popular when they were growing up.
That is, why is Java's philosophy, everything is private, getters and setters everywhere? I presume it's because people were going crazy in C++ just reaching into other people's pointers and fucking with shit.
And why is Python's philosophy, everything is public, don't touch anything you don't know how to use? I presume it's because people got fed up with Java making everything private and sealing everything off.
... and of course, then Java has static anyways and Python added properties, so so much for "philosophy."
But yeah, ultimately, as long as you're working on your own or your team's own code, any problems you run into will be minor speed-bumps compared to problems arising from programs/packages you have to interface with. The maybe 10 extra minutes you spend typing "self" in Python repeatedly is going to pale in comparison to the hours you have to spend trying to coerce some environment crap into working.
Java's philosophy borrows heavily from the encapsulation tenant of object oriented design. That's why Java looks like it does.
OOD existed long before Python, but it don't think it was designed with objects in mind. It went for a more natural language design, near as I can tell, rather than buying into the computer science terms and ideas.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
There's nothing wrong with java's encapsulation and private-first sensibilities, the issues is that the language doesn't do anything to sand away the rough edges those mandates create. Ruby for instance, instance variables are also private by default, but if you want to make getters and setters you just use a keyword that generates all the ones you want for you, and they're named such that instead of calling .get_variablename you just call .variablename as if it were not a private member.
Some of the problem with java is not actually a problem with java but with the conventions set by the community. The java 'style' (and the style of the base class library) has very wordy variable names ("SimpleBeanFactoryAwareAspectInstanceFactory" is a class from the Spring library, "InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState" is a class in Swing which is part of the java standard library!). You don't have to follow those ridiculous naming conventions, but you sure are going to have to type a lot of long class and method names that were written by other people. This problem is exacerbated by the cruft in the language. You'll commonly be typing not only these wordy names but also be typing keywords like public or protected in front of them, or writing those getter and setter methods. Even if you personally use reasonable variable names you'll find yourself having to write things like "public InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState getReasonableVariableName()". That's an extreme case obviously, but java is notoriously chock full of verbose class names.
I don't think long method or class names is really an issue. If I had to use that class, I'd type Inte then hit ctrl+space and be done. Same as the complaints of public static void main(String[] args) being overdone. How much of that are you doing? I leave it all to the IDE.
I've only worked professionally with Java and Python, and my opinion is that Python is great for small, quick projects, but I much prefer Java for big long-term projects. I wouldn't want to work in C or C++ because I like having lower-level problems abstracted away so I can focus on the problems that add value to customers.
But ultimately the company you work for and the people you work with are more important than any question of language.
Well sure, your IDE can fill all that in for you, but it can't read it for you. The method/class naming conventions in java are a real problem, and I'm 100% sure they're a significant reason developers find java arduous.
I don't think long method or class names is really an issue. If I had to use that class, I'd type Inte then hit ctrl+space and be done. Same as the complaints of public static void main(String[] args) being overdone. How much of that are you doing? I leave it all to the IDE.
I've only worked professionally with Java and Python, and my opinion is that Python is great for small, quick projects, but I much prefer Java for big long-term projects. I wouldn't want to work in C or C++ because I like having lower-level problems abstracted away so I can focus on the problems that add value to customers.
But ultimately the company you work for and the people you work with are more important than any question of language.
I think I'd rather work with C++ than Java. But only just barely.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
One of the questions I've asked people at the 'problem solving' part of programming interviews is 'how would you write code to come up with the result of a move in the game of Battleships' -- so they have to think about how to represent the board, the ships, changes in state so they know when a ship is sunk, etc.
Most people come up with some sort of Ship object; when I was talking through this with another dev to make sure we could solve it _ourselves_, I was surprised in retrospect to notice that my instinctive solution was a grid containing pointers between the cells for a given ship, and no "objects" at all, just a bunch of dumb structs -- so I guess I think in C unless I have a reason not to?
The easiest solution for battleship is a 2d array of something that has three states (empty, full, and hit), and a "place ship" routine that places items in the array.
Going OO for battleship is asking for trouble I think, because you're making the complexity insane for the solution.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
A fun follow up question after someone comes up with the array solution is, "So what if the board was 10 million rows by 10 million columns?"
A fun follow up question after someone comes up with the array solution is, "So what if the board was 10 million rows by 10 million columns?"
Depends.
Tell the customer their requirements are bad and they should feel bad.
Keep with the grid solution and hope you can keep it under 2 gigs because there's a good chance a customer requesting it isn't running a 64 bit system.
But really, you'd virtualize the grid, iterate over the ships and do hit checks on the ships with their own location in that 100 trillion number grid instead of representing the empty space as actual memory.
No one would ever play that game.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Exactly -- depending on which way around people go we can take the discussion different places. Some people get stuck pretty early on with things like:
....
.SS.
.SS.
....
because they don't have a way to tell if those submarines are horizontal or vertical, so hitting (2,2) and (2,3) (edit: bah, code blocks are 1-based index) may have sunk half of two submarines, or all of one; some people have objects with a counter of number-of-hits per ship, which fails when you shoot at the same square twice. Then there's how you represent the ship; is it start pos + direction + length, or an array of booleans, or something else?
The optimisation ones are fun, because a solution that works for four ships in a million by million world doesn't scale the same way if the board is almost full and you have ~O(n^2) ships instead. (plus time -vs- memory, etc)
Basically all I wanted to have happen during the interview was for them to say "oh, _right_", at some point; if they get stuck further on and have to backtrack, that's fine, I just wanted to see that they can think about a smallish problem sensibly. Some people took 45 minutes and still hadn't got the basic answer solved; one guy had got the basic thing done in a few minutes and we were well onto the different sorts of O() ways it could scale, which was much more like it.
djmitchella on
+2
Options
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
And then you can get into the more interesting stuff like approximate inverse solvers and matrix preconditioners.
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
I'm turning into a grumpy old man who's liking just straight C more and more.
But straight C gives you basically no way to be safe! Its compile time computation is bloody text replacement. And its standard library makes C++'s look rich and fulfilling.
You can use C++ as C with niceties like templates, constexpr, references, etc. if you really really like C...in that role IMO it's a better C. Okay it's missing variable sized arrays, but whatevs.
Can anyone recommend tools for annotating screenshots or banging out quick screencasts? I'm writing up some tutorials, and I'd like to show highlighted screen regions (even just outlined is okay) and animated GIFs of clicking through menus.
Loaded question: How is it being a Java developer - one of the options available to me is to retrain into a development role. Just curious about it.
The easy answer is "terrible", I'm not sure any of us truly like Java. Really, though, the overall work environment will matter FAR more than the language. I find java tedious and overly verbose in most cases, but once you're working with something 8 hrs/day and aren't restricted to core libs by school, then that is probably the least of your concerns.
Academic here, not professional. I like Java fine. Ultimately, I'm pretty language-agnostic. I like Java as much as C++ or C# or Python, as languages. They have their respective pros and cons, and people have different preferences, and a lot of these preferences are culturally driven as backlashes against whatever was the most popular when they were growing up.
That is, why is Java's philosophy, everything is private, getters and setters everywhere? I presume it's because people were going crazy in C++ just reaching into other people's pointers and fucking with shit.
And why is Python's philosophy, everything is public, don't touch anything you don't know how to use? I presume it's because people got fed up with Java making everything private and sealing everything off.
... and of course, then Java has static anyways and Python added properties, so so much for "philosophy."
But yeah, ultimately, as long as you're working on your own or your team's own code, any problems you run into will be minor speed-bumps compared to problems arising from programs/packages you have to interface with. The maybe 10 extra minutes you spend typing "self" in Python repeatedly is going to pale in comparison to the hours you have to spend trying to coerce some environment crap into working.
Yeah, like I said, in the end the language will not really be the problem. I find Java super verbose and super restrictive. I'm aware that this has been made worse by the majority of my Java experience being school projects rather than real code, where I was having to make Java do things it's not great for in the first place (CLI apps, etc) using only the standard library.
Java's philosophy borrows heavily from the encapsulation tenant of object oriented design. That's why Java looks like it does.
OOD existed long before Python, but it don't think it was designed with objects in mind. It went for a more natural language design, near as I can tell, rather than buying into the computer science terms and ideas.
Yes and no. Python is very highly OO. Everything in Python is an object.
>>> def foo():
... pass
...
>>> dir(foo)
>>> foo.__class__
<type 'function'>
>>> x = 1
>>> x.__class__
<type 'int'>
It does not force an OO syntax on you, though, because for actual logic and code organization that is not always correct.
Does it matter if any of those are an object underneath or not? Is that significantly different than any other language with a C based syntax? The stuff like __class__ above is not anything you normally use. If you are, you're probably doing it wrong.
Does it matter if any of those are an object underneath or not? Is that significantly different than any other language with a C based syntax? The stuff like __class__ above is not anything you normally use. If you are, you're probably doing it wrong.
I've concluded it's impossible to write phpUnit tests for Drupal 7. By the time I abstract all the drupal specific shit out of my code there's nothing left to actually write tests for.
My task: sales orders need to be processed post checkout. Each product in the order has a backoffice value, generate a purchase order for each backoffice containing only those products that use that backoffice.
What I can actually write a phpUnit test for without using any drupal procedural functions: take this array of values and separate it into multiple arrays
So when the code fails because product X in the database doesn't have a backoffice assigned, and someone asks me if there's test coverage, my answer is going to be "sort of???". It's not like I can write a unit test to load items from the database and check their integrity.
Why are you unit testing this? This is a perfect example where all you care about is an integration test.
Unit testing was part of the work spec, as part of a recent company-wide push to get more test coverage on logic-heavy projects. But I think unit testing was only put on there because integration tests in drupal are so slow. I really wish there was a middle ground. I actually had, for a few hours, a ghetto-ass testing framework that was just a page handler and a self-made assert function that called drupal_set_message with either status or error messages.
I've actually reduced my entire output to a shell function that just passes the order id off to the existing backoffice processing functions, so the existing tests for those are responsible for nearly everything I was going to write a test for.
So the correct answer to "product x caused a failure because it didn't have a backoffice assigned" is now "if you want to unit test data integrity it should be done as part of the product import module, not the backoffice processing module".
It's possible to write Java that isn't an endless stack of frameworks and getters and inheritance and BeanFactoryProxySingletons.
It's possible to write good functional Java using Java 8 constructs and a decent (far from perfect) static type system.
It's possible to write performant Java, leveraging the very, very good JVM (in ways that many JVM languages don't, simply because their model isn't as good a fit), and maintanable Java, using a well-developed testing infrastructure and probably the best refactoring tools of any language.
It's possible to write good code in any language, but good code in Java has a lot going for it.
It's just that most people don't write good Java.
0
Options
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited February 2017
On the discussion of languages, I think the library environment matters a lot as well. I've been doing a lot of Swift recently working on some iOS prototyping and as a language I like Swift 3 a lot, it's pretty nice. Then you have to call Apple's API's and deal with their native bridging and how nice Swift is, or isn't, becomes completely meaningless.
On the discussion of languages, I think the library environment matters a lot as well. I've been doing a lot of Swift recently working on some iOS prototyping and as a language I like Swift 3 a lot, it's pretty nice. Then you have to call Apple's API's and deal with their native bridging and how nice Swift is, or isn't, becomes completely meaningless.
I never had a problem with that... How do you mean? Maybe it's just due to being so used to an iOS environment that I don't notice anymore...
On the discussion of languages, I think the library environment matters a lot as well. I've been doing a lot of Swift recently working on some iOS prototyping and as a language I like Swift 3 a lot, it's pretty nice. Then you have to call Apple's API's and deal with their native bridging and how nice Swift is, or isn't, becomes completely meaningless.
I never had a problem with that... How do you mean? Maybe it's just due to being so used to an iOS environment that I don't notice anymore...
just the general interfacing with obj-c from swift is a bummer
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Posts
https://docs.python.org/3.4/library/datetime.html is one I'm always stuck on. That page looks like they barfed up a bunch of information into HTML and slapped some bold/italics tags everywhere and figured everyone can just sift through it to figure it out.
Interesting. I see what you're saying, I guess. But really, the complaints are around the choice of formatting of the information and that the tooling gives you the option of doing it kind of shitty and cluttered, then?
If you use docstrings and Sphinx' docstring parsing, you get the stuff like https://python-docdown.readthedocs.io/en/latest/docdown.html#module-docdown.docdown which is about like using javadoc. The other things you are complaining about, I'd bet, are basically hand built HTML (or really hand built RST converted to HTML). So the tooling exists to do exactly what you guys would like, but I can see the argument that the dev community does not exactly encourage it and instead tends towards a bit more of a mess.
I'd actually love to hear your thoughts on documentation such as found here https://smartdevicelink.com/en/docs/iOS/master/ and the other docs there. The documentation generating platform was built by my employer. It uses markdown, some markdown extensions which we/the client open sourced, and can be built from markdown docs on github and inline doc stuff from javadoc, doxygen, and jazzy. I believe there are hopes to open source all of it, but I'm not sure exactly when or how it will be broken up as there are certainly parts of this platform which are project/implementation specific.
The easy answer is "terrible", I'm not sure any of us truly like Java. Really, though, the overall work environment will matter FAR more than the language. I find java tedious and overly verbose in most cases, but once you're working with something 8 hrs/day and aren't restricted to core libs by school, then that is probably the least of your concerns.
I used Java when I was in school, but haven't used it professionally. I have used C++ and Python professionally in an embedded environment for the past 4 or so years. So de-rate the following appropriately.
Excellent documentation, good library support (but not as easy to install and use as say, Python's massive library where I can pip install a package and be up and running in five minutes), generally easy to use with some significant warts.
Good: reflection is handy, and the type safety means there are vast classes of errors that'll be caught at compile time instead of runtime (my biggest complaint about Python. Duck-typing is great for quick and dirty hacks, but maintenance requires vast testing infrastructure to make sure you didn't accidentally pass in a type that will work for the every-day use-case, but will blow up for the rarely-taken execution path). Lambdas, try-with-multicatch, try-with-resources, a generics system that isn't turing complete, a not-completely-insane package system are all helpful.
Biggest warts I ran into were things like const-correctness (Java doesn't make it easy to do, or even possible for things like arrays), compile time computation (not available), exception specifications (they tend to infect everything), finalizers instead of destructors (can't do RAII), and no first-class functions (but at least now it's possible to pass methods, woo!). Another issue is the massive object-oriented-bullshit infrastructure many projects seem to have picked up while using Java. That's not a complaint about the language, but instead about the language community. And of course everything requires at minimum a class, but that can end up simply being a namespace for your functions, so I don't see that as a big deal.
Those were people from my company, using a system that I built to organize.
I'm so proud 8->
Academic here, not professional. I like Java fine. Ultimately, I'm pretty language-agnostic. I like Java as much as C++ or C# or Python, as languages. They have their respective pros and cons, and people have different preferences, and a lot of these preferences are culturally driven as backlashes against whatever was the most popular when they were growing up.
That is, why is Java's philosophy, everything is private, getters and setters everywhere? I presume it's because people were going crazy in C++ just reaching into other people's pointers and fucking with shit.
And why is Python's philosophy, everything is public, don't touch anything you don't know how to use? I presume it's because people got fed up with Java making everything private and sealing everything off.
... and of course, then Java has static anyways and Python added properties, so so much for "philosophy."
But yeah, ultimately, as long as you're working on your own or your team's own code, any problems you run into will be minor speed-bumps compared to problems arising from programs/packages you have to interface with. The maybe 10 extra minutes you spend typing "self" in Python repeatedly is going to pale in comparison to the hours you have to spend trying to coerce some environment crap into working.
OOD existed long before Python, but it don't think it was designed with objects in mind. It went for a more natural language design, near as I can tell, rather than buying into the computer science terms and ideas.
The "everything is an object" was a good idea, just Java didn't really do it well enough IMO.
we were simply shocked to discover that giant hundred-developer state machines are actually bad
Some of the problem with java is not actually a problem with java but with the conventions set by the community. The java 'style' (and the style of the base class library) has very wordy variable names ("SimpleBeanFactoryAwareAspectInstanceFactory" is a class from the Spring library, "InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState" is a class in Swing which is part of the java standard library!). You don't have to follow those ridiculous naming conventions, but you sure are going to have to type a lot of long class and method names that were written by other people. This problem is exacerbated by the cruft in the language. You'll commonly be typing not only these wordy names but also be typing keywords like public or protected in front of them, or writing those getter and setter methods. Even if you personally use reasonable variable names you'll find yourself having to write things like "public InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState getReasonableVariableName()". That's an extreme case obviously, but java is notoriously chock full of verbose class names.
I've only worked professionally with Java and Python, and my opinion is that Python is great for small, quick projects, but I much prefer Java for big long-term projects. I wouldn't want to work in C or C++ because I like having lower-level problems abstracted away so I can focus on the problems that add value to customers.
But ultimately the company you work for and the people you work with are more important than any question of language.
I think I'd rather work with C++ than Java. But only just barely.
Most people come up with some sort of Ship object; when I was talking through this with another dev to make sure we could solve it _ourselves_, I was surprised in retrospect to notice that my instinctive solution was a grid containing pointers between the cells for a given ship, and no "objects" at all, just a bunch of dumb structs -- so I guess I think in C unless I have a reason not to?
Going OO for battleship is asking for trouble I think, because you're making the complexity insane for the solution.
Depends.
Tell the customer their requirements are bad and they should feel bad.
Keep with the grid solution and hope you can keep it under 2 gigs because there's a good chance a customer requesting it isn't running a 64 bit system.
But really, you'd virtualize the grid, iterate over the ships and do hit checks on the ships with their own location in that 100 trillion number grid instead of representing the empty space as actual memory.
No one would ever play that game.
The optimisation ones are fun, because a solution that works for four ships in a million by million world doesn't scale the same way if the board is almost full and you have ~O(n^2) ships instead. (plus time -vs- memory, etc)
Basically all I wanted to have happen during the interview was for them to say "oh, _right_", at some point; if they get stuck further on and have to backtrack, that's fine, I just wanted to see that they can think about a smallish problem sensibly. Some people took 45 minutes and still hadn't got the basic answer solved; one guy had got the basic thing done in a few minutes and we were well onto the different sorts of O() ways it could scale, which was much more like it.
But straight C gives you basically no way to be safe! Its compile time computation is bloody text replacement. And its standard library makes C++'s look rich and fulfilling.
You can use C++ as C with niceties like templates, constexpr, references, etc. if you really really like C...in that role IMO it's a better C. Okay it's missing variable sized arrays, but whatevs.
Extra points for free and open source.
Yeah, like I said, in the end the language will not really be the problem. I find Java super verbose and super restrictive. I'm aware that this has been made worse by the majority of my Java experience being school projects rather than real code, where I was having to make Java do things it's not great for in the first place (CLI apps, etc) using only the standard library.
Yes and no. Python is very highly OO. Everything in Python is an object.
It does not force an OO syntax on you, though, because for actual logic and code organization that is not always correct.
110 GPU-years/collision apparently
what an interesting measurement
lol why?
Does it matter if any of those are an object underneath or not? Is that significantly different than any other language with a C based syntax? The stuff like __class__ above is not anything you normally use. If you are, you're probably doing it wrong.
Tell that to Ruby.
Edit: Oh wait, just checked.....5 years too late!
How fast does a GPU travel in a vacuum?
Unit testing was part of the work spec, as part of a recent company-wide push to get more test coverage on logic-heavy projects. But I think unit testing was only put on there because integration tests in drupal are so slow. I really wish there was a middle ground. I actually had, for a few hours, a ghetto-ass testing framework that was just a page handler and a self-made assert function that called drupal_set_message with either status or error messages.
I've actually reduced my entire output to a shell function that just passes the order id off to the existing backoffice processing functions, so the existing tests for those are responsible for nearly everything I was going to write a test for.
So the correct answer to "product x caused a failure because it didn't have a backoffice assigned" is now "if you want to unit test data integrity it should be done as part of the product import module, not the backoffice processing module".
It's possible to write good functional Java using Java 8 constructs and a decent (far from perfect) static type system.
It's possible to write performant Java, leveraging the very, very good JVM (in ways that many JVM languages don't, simply because their model isn't as good a fit), and maintanable Java, using a well-developed testing infrastructure and probably the best refactoring tools of any language.
It's possible to write good code in any language, but good code in Java has a lot going for it.
It's just that most people don't write good Java.
I summarized it for everyone. :rotate:
I never had a problem with that... How do you mean? Maybe it's just due to being so used to an iOS environment that I don't notice anymore...
just the general interfacing with obj-c from swift is a bummer