Threads for alsolsprit
-
It might be good, but the way they demanded donations in the early days put me off it for life.
-
-
I would argue that; for what they were going for; it is only fair. I can imagine without donations they saw the death march the project would be on.
Besides, as qqlq said, free as in beer vs free as in speech.
-
-
-
I bet Unreal will start eating Unity’s lunch very soon. Unity’s been making a lot of weird business decisions, and Unreal’s been stepping up on their pedagogy (along with being developped by Actual Gamemakers). When people start realizing how easy Stuff like Unreal blueprints makes it insanely easy for anyone to pick up these tools.
Unity still has a good lock on the “people starting out” thanks to all the content, but I think it’ll flip
-
Hopefully Godot will start eating at them both :)
-
I would say the royalties they are asking for is still a big limitation (5% vs flat fee). Lift that and a lot of people would flock to Unreal.
-
-
Even though the twitter-sphere gets really annoyed at this; I believe this is just about the distinction between a “software engineer” vs “software technician” in a sense. We don’t need to all be engineers but we do need to acknowledge the distinction and the need for it.
-
This is not really separating your concerns. Furthermore, has the issue of now having a rigid structure for the children “prop” that is not really known to the outside world, and against how it is normally used which can be confusing (and for most, would result in not really even checking the format for it, unlike a prop). Why not do it like;
<Card size="large" content={{ title: 'My lovely title', }} />-
You can validate the children prop just as any other prop, but to your point I think linters won’t complain if you fail to provide a propTypes entry for it.
Otherwise there’s already precedent for this kind of thing with the children as function pattern, so I don’t think having children be a plain object is too much of a stretch:
<Card>{ value => <strong>{value}</strong> }</Card>-
Good point, although both of the patterns I find a bit… tacky. That could be just personal preference though; I try to ensure children are always of type React.ReactNode, to make components a bit more predictable in terms of their APIs.
What would be the benefit of either case over using a prop to supply the function / config in your opinion?
-
In general, the render prop pattern is useful in a variety of cases; the choice between “children” or another prop name is mostly cosmetic, I think. For components with a single “slot” for children, I prefer to use the children prop for the purpose. For multiple slots, I don’t think I’d choose to separate them from the other props like the author suggests. But at the end of the day, at least for my kind of setup (Sublime Text), I still have to look up the component’s API somewhere…. maybe some IDE feature might make one choice better than the other?
-
-
-
-
At first it seems a bit strange that Epic would award a grant to another game engine but I guess they see Godot as a stepping stone for developers to learn and eventually go with Unreal.
-
I would guess most of their money comes from players rather than Unreal licensing, so maybe the reasoning is that higher quality in game engines overall means more good games [to put on the Epic store]. Whyever - it’s great to see them doing this.
-
That’s a rather new development, though. Licensing the engine is definitely in the companies DNA, it’s their huge innovation from Unreal. (Yes, ID did that as well, but more as a side business, while Unreal was always built as a separate kit)
It could be a way to compete with Unity: funding a free competitor that people may pick over Unity.
-
-
-
Having people that can develop game engines = larger talent pool = more people to poach away into unreal engine as well
-
-
-
-
-
Trying to figure out the details of freelancing in the Netherlands. While I have no entitlement nor expectations, it is quite a taxing thing to deal with immigration-related issues / questions in addition to an already big change. So wish me luck!
-
The Dutch tax agency (Belastingdienst) occasionally hosts informational evenings about how to start your company (mostly geared towards freelancers). See https://ondernemersplein.kvk.nl/evenementen/seminar-goede-start-met-de-belastingdienst/ for dates and info (Dutch).
-
Nice to know this! I’ll attend one.
The main issue for me is not being a Dutch national - as a migrant, there are more things you need to think about. (Also about making sure your visa stays valid, and will be extended.)
-
-
-
Cue in blockchain issues. We’ve seen an interesting version of this play out with ETH and ETH Classic.
-
JSON vs XML are practically different syntaxes for the same thing and it probably doesn’t matter which you choose. It wouldn’t make or break your program, project, or business (except for the fact pretty much every API uses JSON). The example where JSON “loses” is contrived anyhow; it’s not really a good way to structure this kind of data in my opinion.
-
This is not true.
They have both been used for passing around data. However, one of them is actually a markup language. JSON is not for that, and is horrifyingly weird at it because of that.
-
It is true in the sense that they can both serialize any known data (and both require you to figure out your own solutions for e.g. backreferences).
Tooling matters, though. If you aren’t planning to build your own high-quality tooling, you are better off choosing a serialization format which already has it (where ‘quality’ is extremely contextual to both the team and problem space).
-
Yes.
However, my point is that XML is a markup language meaning that it is very good for annotating / marking up documents. Doing that with JSON is a horrifying experience. Hence, they are not “different syntaxes for the same thing”.
-
Anything you can represent with one can be represented with the other.
Doing markup with JSON is a horrifying experience because the tooling sucks. You could (although it would be pointless) provide an editor that presented the user with XML and stored JSON.
That’s what I mean when I say they are different syntaxes for the same thing (as are all serialization formats). The serialization format is one of the least relevant details possible - what matters are:
- The data model, of which the format is one representation.
- The tooling, without which you’re stuck in the stone age, hand-editing files and hoping they work.
My current minimum standards for data tooling are:
- Automatic generation of parsing and serialization code (for any subset of your data)
- Ability to perform validity checking on a given serialization against a model (whether of the complete data model or a slice of it)
You can get this much with e.g. rails today.
-
Yeah… no.
They are not serialization formats. XML for example is a markup language that you program / annotate / markup in. If you want to treat them as “it will be used by the programs only” be my guest, then I don’t care about your format. However, from a language design perspective JSON is not even comparable to XML.
Again, there is a reason our websites are in HTML and not JSON. There is a reason even in JS, with JSX, XML-like syntax comes back around and around.
-
I am beginning to think I understand your point, but want to make sure:
You are talking about languages, but you don’t think languages are serialization formats. On this point I disagree wholeheartedly; even human languages are serialization formats, and computer ones particularly are.
From there, I suspect you are taking ‘as read’ that computer languages are written in a text editor with little-to-no comprehension of the language grammar (perhaps syntax editing, autoclosing tags etc but rarely eg autocomplete for css classes in html files). On this point I also disagree - IMO it’s a tremendous failure of imagination that we’ve stopped at ‘great text editor’.
-
For the data serialization point; maybe I should have been a bit more clearer. Of course we can say that “any deterministic, structured encoding is a serialization format”. That would be first of all way too vague, especially for this discussion, since that is a great chunk of everything. Discussing the differences of XML and JSON requires us to focus on what makes them different there. Sorry for the confusion.
Secondly, while tooling can improve your quality of life a lot; that does not mean it is a part of the language’s own design. Having a language that has been made with the markup on mind is much more different compared to one that was made predominantly for data interchange especially in regards of objects.
And finally, if you have such a tooling that encompasses the whole language to the point that it should be considered a part of it - by all means be my guest. I don’t think a language has to be text based, (for example Blueprint from Unreal Engine should be seen as a programming language) however I believe that the ones we are talking about are predominantly text based. Should there be something that improves both on coding and reading in regards to this discussion, of course that would warrant a new perspective on it.
I hope I have been able to clarify it a bit more.
-
Thanks, that makes sense :)
-
-
-
-
-
-
JSON vs XML are practically different syntaxes for the same thing
In the simplest use cases that may be true, but does everyone really want to reinvent the advanced stuff that some people need? If you need to provide any level of extensibility for JSON you are going to have to support your own system for namespacing, but XML has a standard version of this. It also has multiple methods of validation which interop with the extensibility. If you need a mechanism to convert one document into another then you have a standardised set of tools for transformation. Again, all these tools interoperate to a large degree.
None of these tools are easy, or perfect. They are far from it, created a long time ago (before JSON became popular), and have a lot of complexity (only some of it essential.) This makes the learning curve somewhat difficult, but there is no denying it is a powerful toolset for those that need it. Sometimes it may be worth inventing your own thing on top of JSON, or running with what you feel is a maintainable JSON toolset, but this decision isn’t as simple as you make it seem in all cases.
-
-
JSON vs XML is basically because some lovely people decided to use XML for their data, and JSON works a bit better at that. Sure, fine. Better tool for the job I guess.
That does not mean a markup language (XML - hint at the name) will perform worse in markup than one that is not for markup. Hence, our age old issues.
There is a reason we use HTML and not JSON for web pages.
-
N64N64
edited
3 years ago
|
link
| on:
Frontend Lobsters, what are your pet peeves about the languages / frameworks you use?
You said frontend, so I’ll take this as an opportunity to talk about iOS :D
In general, the move away from dynamic dispatch. I mean, I understand it’s for performance, but it makes things less fun :( I’m also incredibly skeptical of SwiftUI, and am not looking forward to doing jobs/contracts using that framework.
I have a gut feeling Apple’s making these changes purely for “developer PR” reasons, and not because they’re actually good changes. e.g. Objective-C brackets are too ugly -> make Swift, UIKit is too hard -> copy React.js. FWIW I have nothing against Swift but the reasoning behind making it doesn’t make much sense to me, from a technical perspective.
If changes like these continue I will probably switch to backend or embedded or something. At least there, I won’t be subjected to the whims of post Steve Jobs Apple.
-
I am a mobile developer as well, so of course!
I’ve never been able to spend much time on native iOS development however the SwiftUI idea seems good from the perspective of “declarative vs imperative programming”. I can imagine that is the main source of skepticism. Recently the whole FE worlds started to shift towards declarative programming hence the boom.
Why would you prefer imperative programming by the way I would love to have an opinion on that as well.
-
-
-
It is almost surreal how XP is still relevant after 16 years.
-
On the contrary, it is almost surreal that a product launched 16 years ago is deemed to be ancient and in dire need of replacement. Mind, I do understand the reasons for getting rid of Windows XP (or refraining from using it in the first place which has always been the better strategy) but it is telling of the haphazardness of the general computing industry that these products are so fragile.
-
The problem is not its fragility, it’s just that an OS needs to be constantly updated: be it to support new formats, fix newly found vulnerabilities and implement new features.
Nobody says anything that Ubuntu has a new version twice a year, they just keep the same name, that’s all.
-
There should be no need for the OS to be updated ‘to support new formats’, that is the job of services and applications built on top of the OS. If ‘everything is a file’ (unix) the OS only needs to know how to handle files. The problem here is that the definition of ‘operating system’ has been widened to encompass services which do need to be kept up-to-date. If Windows XP only handled the basics - scheduler, memory management, basic user management, IO - there would be a far smaller attack surface and with that a lower number of new vulnerabilities to fix.
Why bring up Ubuntu by the way? This is not a Windows-vs-the-world thing so there is no need to get defensive by pointing out similar fragility in other systems. I pointed a finger at ‘the general computing industry’, not just at Microsoft.
-
While I get the sentiment, I think this is mostly a wording issue - since the kernel is not Windows but Windows NT Kernel. That is still going on and being developed.
The issue is the fact that if it is only the kernel, there is not that much money to be made. Afterall no development is separate from the economics of the real world.
-
…which is one of the reasons why the Linux kernel became the dominant factor in computing it is nowadays. The GPL licence has been an important factor in allow Linux to achieve its dominant status since it has made it possible to keep all improvements to the kernel together in one canonical version which can be used by anyone and everyone. It would not surprise me in the least if Microsoft eventually moves its Windows stack to the Linux kernel to rid itself of the maintenance burden since, as you already noticed, the real money lies in the tools built on top of a kernel.
-
Yes that is true. Albeit I doubt MS would move away from Windows NT Kernel, especially since;
- Personal computing pretty much is almost completely windows. Meaning that backwards compatibility and everything that MS cares so much about - it would be very costly to keep being backwards compatible while switching to Linux kernel.
- Same thing, business deals.
- For business deals, NT Kernel is still a moat they have, meaning that you can’t just spin up a new Linux distribution and compete with MS. You still need all the applications used in Linux as well.
- MS is still heavily investing in this - especially with ARM.
I think MS just realises while they won the PCs, they lost the servers and mobile - and is acting accordingly. They earn way more than enough with Windows, so doubt they’d even need to consider that kind of a cost cutting measure.
-
-
-
-
-
-
-
Developing a shared to-do list application that I want to use with my SO. Maybe will make it open to public as well, although I feel like there are other alternatives so not sure if people would be interested.
-
This link (Merkle Tree) may be helpful and complements the topic about Markle Tree.
-
Book looks very interesting, will read it since it doesn’t look like a lengthy read. Thanks!
-
-
Hi guys, author here!
I’ve just written a very short, hopefully good explanation for merkle trees. More of a layman’s explanation type of a text but would love to get feedback. If it does not meet the requirements (I read them and didn’t see any issues, however to err is human) please let me know and will delete it.
Thanks for your time and have a nice day!
-
I liked this. Thanks. You have a nice voice. Keep up the good work!
I was hoping to find out if this was how you made baby merkles, but it turned out okay anyway (grin)
-
Thank you so much for your kind words! I am a very firm believer in them being delivered by storks but who knows 😂
-
-
I have noticed this wasn’t shared here - wanted to add it. I think it is quite amazing, having read the book cover to cover I can say that it is quite a well made, relatable list of challenges and how they are being resolved in the sector.
Foreseeing these types of issues is hard especially if you never went through the process, and quite hairy to resolve as such I believe it is a very good resource to have.
On another note each section comes with quite a lengthy follow up material, which I found absolutely amazing to use as a starting point as well.