https://www.embassygardens.com/sky-pool/ says this is "coming soon". It will be interesting to see how the actual thing will differ from the architects' renderings.
Thanks, I also found https://www.cnbc.com/2021/04/28/worlds-first-floating-sky-po.... So, unlike what some of the renderings suggest it's not an "infinity pool" but rather has high glass walls on the sides, which was one of the things I was wondering about. It also has those two... cables? running below that aren't on the renderings.
True, but in my experience they are always clearly labeled as such. Whereas Forbes makes the difference non-obvious, as evidenced by commenters on Forbes opinion pieces often saying "Forbes says $thing" rather than "$blogger says $thing".
> Superstar engineer only works a couple hours per day?
Replace the superstar with someone working "normal" hours but in a time zone offset by >= 5 hours to your own. You seem to be saying that cooperation with such people cannot work. But that is simply not true, many companies do make it work.
We had distributed teams with people in different time zones.
The key is to require some defined overlap of working hours. If that's not possible, you divide the tasks as cleanly as possible across timezones so that people in the same timezone can work together.
Trying to force teammates to work together on something in opposite timezones doesn't work unless you have very relaxed deadlines. When someone has to wait until the next day to get a response to any blocking questions, work slows to a crawl.
> The key is to require some defined overlap of working hours.
Sure, that's not what I'm disputing.
> When someone has to wait until the next day to get a response to any blocking questions, work slows to a crawl.
Blocking questions should be an absolute exception in any case, even if the person who can answer them is just down the hall. It's on engineering management to organize work and documentation practices so that people can find answers on their own.
> Here's the summary: [...] But running multi-process is heavy on the JVM as it has to load the virtual machine and JIT for every process start, special when the processes are short lived.
This is a valid summary of some facts, but not of the article or facts relevant to the article. Some quotes:
"Jekyll is not forking processes, so that is not the issue."
"The area where JRuby and TruffleRuby shine are long running processes that have had time to warm up. Based on suggestions I put together a repo of a simple small Jekyll build being built 20 times by the same process in a repo here. After 20 builds with the same running process the build times do start to converge, but even after that MRI Ruby is still fastest."
We don't know that it's really I/O, as in "pushing some bytes to the system". All we know is that the author saw a hot method called "write" and stopped the analysis there. It might well be something like messing around with character encodings to get those bytes in the first place.
Thinking about this more, we know that the author saw a hot "write" method in the profile for the fast run and doesn't have a profile for the slow run. The slow versions could be spending most of their time in a completely different place.
> default unreal 4 templates, art from asset packs
I don't understand this criticism. Using existing asset packs seems sensible to me. It's a tiny team that seems to have more software engineering than graphic design experience. Focusing on the game itself first and using placeholder assets allows them to make progress for now. It can be made pretty later, when there is an actual game. If it were the other way around, people would be criticizing them for focusing on looks first instead of writing game code.
All that said, the rest of the criticism appears damning.
Using content from a wide variety of asset packs is a problem because it means the resulting game will be visually and thematically incoherent. You can see a lot of this already in their demo videos -- there's visible conflicts between their realistic and cartoony content, detailed vs. lo-fi, shiny vs. gritty, fantasy vs. science fiction... this all makes for a real hodgepodge of content in the game, and it's going to be difficult for them to resolve in the future in a game that's meant to rely heavily on user-generated content.
If it's going to be a hodgepodge anyway due to user-generated content, wouldn't that be another argument for not trying too hard to develop their own integrated visual theme?
(Not that I think that "user-generated" content will work well. If any of it is owned, or merely claimed to be owned, by litigious copyright holders, that's a good way to get YouTube to ban gameplay videos. There goes your free advertising. I wonder how Second Life deals with this.)
> If it's going to be a hodgepodge anyway due to user-generated content, wouldn't that be another argument for not trying too hard to develop their own integrated visual theme?
A lot of that depends on what kind of UGC they actually allow. I'm not certain whether they intend to allow users to upload their own content, or if UGC actually just means "build structures in game out of built-in assets". I suspect it's actually the latter.
> I wonder how Second Life deals with this.
In large part, through technical barriers. Second Life historically used a lot of rather idiosyncratic formats for its 3D models (like "sculpted prims" -- in short, XYZ coordinates stored in a texture), making it effectively impossible to import models which weren't created for SL. They did eventually allow users to upload meshes, but that capability is still gated behind some special permissions to prevent abuse.
> I'm not certain whether they intend to allow users to upload their own content, or if UGC actually just means "build structures in game out of built-in assets". I suspect it's actually the latter.
The Kickstarter (https://www.kickstarter.com/projects/playdreamworld/dreamwor...) says (emphasis mine, also highlighted in the article): "Creator centric crafting economy : Using simple tools and guided by quick tutorials, you can learn how to create your own 3D models for items that you and others might need or want in your builds and adventures. Imbue them with useful function like lighting, extra damage, low weight, knockback, and a plethora of exciting magical properties! Not artistically inclined? Import 3D models from anywhere online, and DreamWorld will help you turn them into exactly what you were looking for."
> I don't understand this criticism. Using existing asset packs seems sensible to me
Code reuse is fine, but when 90% of your game is from various art pack, it's kinda like a software project thats 90% copy-pasted from StackOverflow. Sure, reusing 3rd party code is fine, but at some point, they've cross the line into "Do they even know what they are doing?"
With an interpreter, the JavaScript source is compiled to some bytecode, then the bytecode is executed in a loop, instruction by instruction.
With a compiler (not jit), the whole bytecode would be further fully compiled to some C apis before being executed, making it effectively an "ahead of time" compilation.
The catch is : since the code never was executed, there is very little static information to work with, so the compiled output is often just a giant unrolled interpret loop. The compiled version can be like 10% faster on very hot JavaScript loops compared to the interpreted version.
> With a compiler (not jit), the whole bytecode would be further fully compiled to some C apis before being executed, making it effectively an "ahead of time" compilation.
This hinges at least on the question of what you mean by "the whole bytecode". If the source is made up of N functions, and you compile all N functions ("the whole bytecode" of the entire program) to machine code before you know if any of them will be executed: Yes, I'd agree that that's a form of ahead of time compilation. Is this what full-codegen used to do?
On the other hand, if the source is made up of N functions, and you only compile "the whole bytecode" of each of them to machine code one by one, only those that will actually be executed, and only when you are preparing to actually execute them: That's JIT compilation. Even if it is the very first execution (i.e., you have never even interpreted), even if the compilation doesn't use fancy profiling or sophisticated code generation or whatnot.
> since the code never was executed, there is very little static information to work with, so the compiled output is often just a giant unrolled interpret loop
I think you mean "dynamic" information. And "the compiled output is often just a giant unrolled interpret loop" is pretty much the definition of what a baseline JIT compiler produces.
By "the entire thing", do you mean an entire file, without knowing if all functions in it will be used? I'm just baffled because there are several posts here from V8 developers, and quotes from the FAQ, saying things of the form "this is like FullCodeGen, except X", and the "X" is never "FullCodeGen was not a JIT". Which suggests to me that the people closest to development of these things don't think of them in the same terms as you do, which is why I'm trying to understand your terms.
> By "the entire thing", do you mean an entire file, without knowing if all functions in it will be used?
Yes. Afaik full-codegen had no way to discover that.
> and the "X" is never "FullCodeGen was not a JIT". Which suggests to me that the people closest to development of these things don't think of them in the same terms as you do, which is why I'm trying to understand your terms.
If you look at the langage they used, they’d always call full-codegen a compiler or baseline compiler. Not a jit. Because there was nothing to gather time-of-use information from. And full-codegen didn’t keep parse information around which is why crankshaft had to separately re-parse everything, full-codegen could not hand it the source or bytecode of functions to optimise.
There are more examples in the SDK, and the larger projects which have complex drawing going on, show the declarative layout system to its full advantage.
Probably the best liked feature of Beads is invisible in the syntax, as it follows the State-Action-Model pattern (see sam.js.org), and when a state variable changes, any layout that used that variable is automatically regenerated. This is of immense value when you have 500 things on the screen, and knowing which part of the screen to rebuild on any perturbation of the state is actually a lot of work, and the source of many under/over refresh errors.
This might be called a sprinkling of PROLOG's deduction system, where logical implication is done in the runtime. I am not aware of any top 20 language with deduction. The layout system is declarative like CSS, but includes variables, looping, and IF statements to make it more flexible.
The simplification that Beads offers is really only apparent in graphical/interactive software, and client/server programs. Otherwise people will stick to Python, etc.
So it's Basic for 99% of the overall programming, with something like CSS or Android's layout engine thrown in to solve the remaining 1%, specifically laying things out on a screen? Maybe you forgot to link to a convincing example.
