I was just giving the dynamic-typing side of the argument. Being an old-school programmer I'm also skeptical of large and complex applications being written in dynamically typed languages, although I have very little experience writing in any dynamically-typed language other than JavaScript. But I think the typing argument is overblown in general. There are tradeoffs. It's only for really large or complex applications that the disadvantages of dynamic typing start to weigh.

I do think dynamically typed languages allow greater development speed on the front-end, where a lot of it is being done for display only anyway. In Angular if I want to add another property to a data structure I'm using I can generally just add it to the JSON output by my API and add a binding to my template and I'm done. If I later want to change it to a string from a date, I just do it and Angular gives no ****s. With static typing I'd need to go make changes to like 5 random files and recompile. That sort of thing adds up. But obviously the tradeoff of lessened data integrity matters a lot less when the data is only being used for display.

I've heard this argument before, but this isn't really about dynamic/static typing in the sense most people mean it.

For example, we used Mongo and Java and in a few cases we'd just pass the DBObject around instead of creating an actual model class (Pros and Cons...). This is effectively the same thing you're talking about. You could add/modify fields without having to change all of the code using the object.

Swift.

Seems like an implementation of the singleton design pattern.

It's not a singleton. It would be something like if you had a blog post collection (standard Mongo example!) and instead of having your back end pull individual blog post documents and immediately converting them into standard Java "BlogPost" model objects, it just passed around the object from Mongo (which is basically a map).

Or another way of looking at it, a JSON object is roughly equivalent to a Map of Strings to values. If you really want the functionality of being able to add new arbitrary keys and modify the type of the values you're passing to a function - you can just pass a Map<String,Object> in Java.

Sure, but at that point you're hacking Java to avoid the type system and turn it into a poor man's dynamic language. But you still have to write gross stuff like "Map<String, Object>". I guess your saying you can always drop down into that when needed, and write normal typed Java the rest of the time, which is fair.

One fair criticism is that it's much harder to design a good statically typed language than it is to design a good dynamically typed language, not to mention that many more ideas can be tried for dynamic typing because implementation is much more accessible, which means the average popular dynamically typed language will have less "gross stuff" than the average popular statically typed language.

With that said, I don't think Map<String, Object> is particularly gross - types exist regardless of whether they are stated. What would be gross is having to cast if you have a deeper structure but that can be fixed with with classes. You can fix any problem in Java by just writing more classes.

haskell is strongly and statically typed. its type inference allows you to avoid almost entirely the unsightliness you see in java generics or C++ templates. calling them gross is a justifiable and appropriate design critique, imo.

Java is verbose, no doubt about it. But its a minor complaint to me because of modern IDEs.

I'm just saying if you feel strongly about this feature of adding/modifying values/types then its not hard to implement in Java. And there are times where that's a really good clean solution.

And if its poor design in Java, its probably poor design in other languages as well.

your other points are fair but i disagree with this one.

languages are designed to be used a certain way. some languages have good support for styles of programming that would be awkward or forced in others. a snippet of first-rate C programming, translated directly into ruby, eg, is going to be really bad and unidiomatic ruby code. but it doesn't mean the C is bad.

I meant that comment only in terms of the specific use case we were discussing.

I completely agree with you in general.

Edit: Meaning, that the approach of writing code that can handle a big bucket of arbitrary key/value pairs should probably be judged based on the context of the situation and not really on the language being used.

Off the top of my head, I can't really think of any situations where I'd want to do it in Python but not in Java.

sry did you already explain why you think large Python codebases are harder to maintain than Java ones?

I didn't really and its a complicated subject with lots of valid opinions on both sides.

But I'll give you a random recent example. We have a python application that sends jobs to a Java application. Both languages chosen for good reasons.

I had to remove a big feature recently. The Java app took under an hour to do. I just deleted the model object and followed my compile errors until everything was nice and clean. Python took significantly longer. It's not as easy to figure out all of the places where code is used. We have decent but not perfect test coverage (say 80%) so there's always a small risk I missed something.

hmm that's interesting, i thought part of the "fat model" philosophy in MVCs is to address this issue...so your code in any language is more or less in 1 place. i wonder if using a framework like Django would help for something like this, since its 'apps' approach helps keep things isolated.

can you talk more about when you choose python vs java? naively, i'd assume python for the part where you're iterating and adding features constantly, and java for more static portions.

thanks for sharing!

We chose Python because we needed something fast and we both knew Python well and Java Web Server frameworks sucked (I'm guessing they still suck - but I have no idea).

We chose Java because we needed to use a bunch of open source projects that are written in Java.

capstone project may be writing a web-based inventory system for a local charity

pretty cut and dry basic stuff, sounds like a perfect excuse to go rails or go home

even found an open-source inventory management system to reference in case I can't figure stuff out on my own

still, seems very simple, achievable in the time frame, and like it could actually help people. Very excite. Reason I'm still awake actually.

I wonder if you found mine.

An inventory system appears super simple until you actually do it. All of a sudden, you find the world is best represented in circular references.

A simple starting point:

you have a table, sku_upc (pk on sku, unique constraint on upc), which obviously maps skus and upcs. Easy start, no problem.

All is fine and dandy, except now you run out of stock on one item, which is fine because you can get some more from your friend down the street. The catch is he has a different sku_upc pairing. Not the end of the world since it is all white-labeled.

great, you build a mapping for that. Add a few tables and problem solved.

Now you get some new supplies from overseas and you see they made a mistake on the SKUs, but that's okay because you can map the new sku_upc to the original and all is fine. Sure, you take a hit on speed, but at least you are accurate.

You open up another box and now you see China actually printed the same upc on every single item in a 50,000 pc container, but at least they kept the *most* of the skus different. You look at the schema design and realize that you are ****ed. The customer is calling you whining that they can't spend the money to pay people to retag all the items, and it is absolute bull**** your inventory system can't handle this case.

Did I forget to mention all of the one-off products they brought from home that don't have upcs on them?

Anyways. That is day one. good luck.

yeah, hoping to avoid SKUs and maybe implement some manual system where you start typing the name of a product and it auto-suggests any matches. It's supposed to work, not be absolute production quality. Something they can take to their IT folks and have them bulk up and deploy if it works well enough.

Definitely not a good idea. I've seen the results of systems that do that, and it is far from pretty. Besides, you need some unique identifier for each product, so may as well make it a sku.

Semi-retorical question:

Would it be uncouth to ask for feedback on these coding tests I'm taking? If I'm spending 1 to 2 hours on these things, why can't I get something like

did ask one time, but it was for some recruiting site. They said something about policies. Well, okay. I wasn't really interested in working with them ever again anyways, but that response cemented my opinion of them.

Are there any nearby organizations or meet ups that do mock interview-type stuff where you can get that kind of immediate feedback?

I should clarify that they may not have any hardware to support scanning SKUs. One of the other companies did, but as you mention that sort of sounds like a nightmare.

Out of all the options it does seem the least overly complicated for the coding level we're all at.

A sku is an alpha-numeric, usually human created, that identifies the product. A UPC is a government-issued numeric code. UPCs are actually a fascinating subject: https://en.wikipedia.org/wiki/Universal_Product_Code

I have seen some variations though. For example, some consignment stores have a sticker on the product with a 6 digit code on it. I'm guessing this is machine-generated, so when they enter the code, the price comes up on the register.

You need some sku because there are only so many ways to uniquely identify a product without getting stupidly inconvenient, and none of them will really work.

Suppose you are only selling blue jeans. How would you create a new sentence to describe every single pair of blue jeans you have in stock? Sure, you can do brand, gender, size, etc, but what about style by year, by season, one has holes, one doesn't, etc. The sentence you have to create are going to get very large, and once you have a drop down of 10 items, you are going to get a mess of duplicate data. Granted, there is no insurance against duplication with SKUs, but it won't be nearly as bad.

you mean when you do a test for an interview? i think it's totally appropriate to ask for feedback. obv be nice about it, but my feeling as an interviewer is i owe that to the person. many people don't ask for it, though.

The going process seems to be: send in resume; phone chat; homework test; etc.

At a whiteboard, it is pretty easy to have the conversation, but I'm wondering about the homework tests. If I do ask, do I ask when I submit or after I am rejected? I feel like both have negative points.

I know that the code or response isn't going to be amazing if I push back 50 LOC in an hour. I'd rather discuss what I would do different if I wasn't just rushing out an answer, so it almost feels like I would get judged on something that really doesn't count.

Agile folks who groom cards with designers, any tips on keeping sub hour meetings? It seems to devolve into design review rather than scoring points most of the time