This isn't the first time I hear this, but I always have a bit of trouble with this one. It's one thing to take a step back and think about the actual product and how it'll be used, but I think it's presumptuous to think that software engineers know what makes a product good or not. We don't say "Everyone needs to care about software architecture, even Product", so I'm not sure why we think the flip side of that is true.
> We don't say "Everyone needs to care about software architecture, even Product"
We absolutely should say that. I was an engineer for 13 years and have now been in Product for 8 years. I work on a highly technical Product team, and it is absolutely an expectation for myself, my peers, and my reports that we should ensure we fully understand our Product, including its software architecture, and have an opinion about it. Engineering ultimately decides the "How", but they cannot do that effectively if Product cannot articulate an opinion about the architecture guided by an understanding of things like expected scale, potential future integration decisions, and other cross-organizational expectations that may not yet be codified. In general, Product should have an educated opinion on anything that is a one-way door, and so should Engineering. It should not be a unilateral decision, and if either party is unable to form an informed opinion, that's an organizational miss.
If you consider product as a proxy for customer, I think it gets a bit easier to understand. Customers don’t care about architecture (unless you have a technical product where they do actually need to know architecture). They don’t care about many of the details. They just want their problem solved.
For software engineers, our goal isn’t to necessarily know what makes good product or not - but we do need to make sure that what we’re building solves an actual customer problem or need.
At the end of the day, the goal is to make a product that people find useful. How that ends up happening is almost completely irrelevant to the people actually using the product.
I really don't think Yakuza games are anything like GTA besides "being in a city". Yakuza has none of the sandbox elements like GTA, the city is more like an elaborate menu to go from mission to mission/side quest/activity.
I'm not sure who this is for. On one hand multiplayer games are complicated to make, even with a dedicated framework, but on the other the tutorial wastes time explaining to me how to undo with ctrl+z and there's even a large infobubble on how to copy and paste text.
This is good feedback! I thought it’d be a great first programming language for people and so I think I have aimed the tutorial far too basic, probably even for them. Maybe that’s where I am losing people. I am going to edit it and see if that improves the retention.
This is an impressive project and hopefully it will allow more programming beginners to get into multiplayer programming. Huge congrats. However, I am wondering: if your programming language is aimed at complete beginners, why make your language untyped and include undefined? Those are both fully loaded foot cannons. Sure, the language looks more inviting and probably gives the impression of faster development, but I'm not sure it's worth the amount of bugs that will be introduced eventually.
Yes, in the end I just made this decision pragmatically and it's not a grand statement about how I think programming languages should work. I felt that it would be possible to add gradual typing to Easel eventually, and so chose to prioritise other programming language features.
One of the original "agitators" which caused me to make Easel was because I was so surprised at how popular the modding tools for my previous game were with first-time coders. The modding tools used JSON, which might sound primitive, but if you look past the JSON it was actually defining a hierarchical declarative language for defining game behaviour. I have many theories for why first-time coders could just pick it up, but one of them is I think the hierarchical shape meant everything could be written inline, without indirection or jumping around. This format allowed all these gamers to just accidentally fall into coding and it was quite impressive how far they got without any help.
But those old modding tools were quite limited really, and that limited how much coding people could learn. So for years I just kept wondering what would happen if someone made that magic hierarchical declarative shape unlimited by merging it with a traditional imperative programming language. Would it allow gamers to accidentally fall into learning actual coding? It took me about 2 years to squash together these two seemingly-opposed paradigms and make the Easel programming language. Doing this required slimming down on the other language features in order to iterate quickly on this big problem, so that's how we ended up not having strong typing, amongst other things. But I don't regret what I chose to prioritise, and I hope to address this in the coming years!
This are just dumbed down phones in a sense: I don't want my mp3 player to be running android. I want a minimal piece of software that lets me quickly navigate to the songs that I want, and physical buttons to do it. I've look long and hard for something like this and cannot for the life of me find it. I'm really sad that I lost my Ipod classic 10 years ago.
Not being a rock star but showing potential is great. But there are some people who are allegedly always busy, in over their head, etc. And these are the type of people I agree that should be avoided. I've found that more often than not these people are always wasting time in meetings, chatting it up, only to complain about lack of time 1 hour later.
I'm not saying don't socialize and just work ; you just need to balance the two.
This is amazing news. As a long time IntelliJ user (Android dev for 7+ years) who wants to start doing more c++, having free access to Clion is a godsend.
I had trouble believing anything in the article since every sentence or 2 has a link to "the best laptop" or "the best powerbank". Just seems like a hub for a bunch of links to sponsored content.
I used sbt in my previous job and didn't hate it. All I want from build systems is to get out of my way and it let us do that pretty well. Very simple to add new tasks as well.
Some excellent VPS deals with high storage here. Host has a good rep on LET. Believe these promos are ending soon and many are sold out in any case, but I think they have some stock in a few of them..
Dreamhost shared unlimited is good for this I think. 3,95 - After 3 years the price triples but still worth it. Unlimited traffic, bandwidth, emails and subdomains.
Some options that pop up frequently on HN: Vultr, DigitalOcean, OVH and Hetzner Cloud, all have cheap VPSes, $4-$5 per month for the cheapest I think. And usually if it's an app for just you/your small family, you can get away hosting multiple apps per VPS without suffering atrocious performance (depends on the apps/usage obviously).
The trick (and somewhat the drawback in many's eyes) is to rent a VPS (or dedicated/bare metal) instead of a "App hosting service" (what Render is). You'd need to know some basics about infrastructure and networking, but not anything too advanced and that's stuff will be useful regardless too, so not too easy to rationalize away :)
This isn't the first time I hear this, but I always have a bit of trouble with this one. It's one thing to take a step back and think about the actual product and how it'll be used, but I think it's presumptuous to think that software engineers know what makes a product good or not. We don't say "Everyone needs to care about software architecture, even Product", so I'm not sure why we think the flip side of that is true.
reply