"I can't imagine how that would work"
-> hearing that kills me inside :(
I think we have 2 options:
OPTION 1)
We've reached a plateau -- software will continue to be developed as it is now, no new abstractions.
OPTION 2)
Mankind will create a better set of tools to:
- reduce the effort needed
- increase the # of people who can participate
in the translation of ideas/requirements -> software.
For everyone's sake [1], I really hope it's the second! :)
As one crazy idea, imagine if you could have a spreadsheet that would let you build software instead of crunch numbers...
... anyway, probably a bad idea, we should stick to our current abstractions and tools :D
[1] Take the above with 2.42 lbs of salt, I'm the founder of
I think dates, times, UTC offsets, and locales/cultures is a topic we frequently think of as "that's easy" [1] when in practice it's painstakingly hard to get right.
As an example, we've spent the past few days on our eng team refining our spreadsheet functions for date/time handling, and it's like the 5th time we've iterated on this (after supporting everything Excel / Google Sheets do).
Funny part is, I'm sure we'll iterate on it even more -- it's hard to get this topic both right & make it easy to use / approachable.
Btw, does anyone have good reading materials on this topic? (date/time/locale handling)
[1] I'm biased as a founder at https://mintdata.com, but thankfully our engineers set me straight on the subtleties :D
>Btw, does anyone have good reading materials on this topic?
I had a slide deck somewhere from when I was at a broker trader and leap seconds mattered (they (can) happen around 10am in East Asian markets on Jun 30).
The moral of the story is: time measurements are fractally wrong, it doesn't matter what format/time system you pick, there will be a use case that breaks it badly. Local time + timezone, epoch, UTC, ATI, doesn't matter it will break somehow.
Your MintData software looks great. I would love a reasonably MS Access type app like this priced at a level I could recommend to or use on behalf of family members.
I hopefully and naively clicked pricing ;)
Some honest feedback would be to rename Personal. Personal account usually mean individuels, but no home user or hobbyist is going to pay $95/month unless they are making money from it.
Any developer who thinks dates, times, UTC offsets and locales/cultures is "easy" is grossly incompetent (unless, of course, they've never worked with human-facing software before, in which case their naiveté can be forgiven).
“Human facing”? Any software worth it’s salt needs to deal with this stuff. Unless it’s a toy program. I quite enjoy Timezone stuff, perversely. Might be Stockholm?
If you're writing firmware for an embedded device without a clock then you'll never have to deal with this. If your software only ever has to interact with other software then you wouldn't ever use time zones unless you really have to. Only humans demand time zones.
We’ve used this API in our https://mintdata.com/docs examples, but the limits run out fairly quickly.
Would be curious to ask here — are there any alternative APIs you’d recommend for showing financial application examples? (Ideally something that fetches the delayed price of a stock (CUSIP) and related news for it)
I'll take a stab at this, Kyle just shoot me if I get something wrong below :D
1) There's a server-centric approach and a client-centric approach:
--a) hand-maintained HTML + php falls into the first camp
--b) React (/Angular/Vue) fall into the second
2) If you go with the second camp (b), you end up having a higher initial page load time (due to pulling in the whole "single page app" experience), but a great time transitioning to "other pages" (really just showing different DIVs in the DOM)
3) Gatsby does some very clever things under the hood, to make it so that you get all the benefits of the second camp, without virtually any downsides.
4) There are of course all kinds of clever code-splitting, routing & pre-loading things Gatsby does, but I hope I got the general gist right.
If not, Kyle, get the nerf gun out! -- how would you describe the Gatsby (& static sitegen) benefits? :)
Gatsby can also let you use react components to do some pretty clever things around image resizing, effects, etc that you might expect from a static site generator but couldn’t achieve with just a frontend framework.
(3) is incorrect, Gatsby initial page load times are mostly really bad.
(2) is both overstated and overvalued. It's overstated because loading a static HTML page from a CDN is extremely fast. Too many people who point at this advantage for SPAs are thinking back to pre-CDN usage with slow origin servers. Of course there are still use-cases where going to network is not wanted, but these aren't the primary use-cases that Gatsby covers.
It's also overvalued in that most users are not getting to a page by navigating in a loaded site, they are coming from a social or search link (again, for the sort of use-cases that Gatsby pages are built for).
> (3) is incorrect, Gatsby initial page load times are mostly really bad.
This has not been my experience, considering all HTML is ready to go from last byte so that other than blocking CSS, rendering can begin ASAP. At this point, no JS is required to interact with the page so things are generally pretty snappy while we wait for React hydrate to kick in.
camp 1) at best, a TCP connection is re-used, and the HTML for "page 2" is fetched over the network, parsed, the CSS OM is applied, and then the whole caboodle* is "painted on screen".
camp 2) the CSS OM is applied and "page 2" is painted on-screen (possibly even faster if the browser cached "page 2" in a texture on the GPU, so the CSS OM application step may be optimized away)
So I genuinely don't understand how fetching a "page 2" from a CDN
(we use Cloudfront & GCP's CDN at https://mintdata.com, so I'm basing my experience on this)
is faster than the SPA approach?
I am genuinely curious on the above -- not trying to start a flame war :D
* Yes, apparently caboodle is a word?! I had to Google it just like you to make sure :)
Wow MintData looks so cool! I was just trying to figure out whether Webflow can be used to build simple apps, then I saw this, a whole new level. Is there a way to try it?
First, big props for shipping stuff that people use.
Second, I've [1] often compared 90% of what we do in software development to being highly trained baristas. Granted, this buys me little love from engineers & even less from Starbucks.
To the point -- I think it's time we rise up & start to use more powerful tooling.
Tooling that:
1) Lowers the barrier for who can author software (really, web-based interfaces that help us get stuff done, the way we want to accomplish a task)
2) Doesn't introduce more chaos (disparate data spread across 10 SaaS products, death by 1,000 spreadsheets by email or in Google drive, no centralized/secure/managed storage, etc)
3) Emphasizes that a superb user experience is table stakes for such tooling.
Thoughts?
--
[1] founder of https://mintdata.com here, so just a tad biased, take the above with a few pounds/kilograms of salt.
[2] oblib -- DM me, we're happy to give you free access if you'd like -- the above wording just warms our collective hearts.
I'm going to disagree here, though sort of understand what you and the original poster are saying.
In short I've seen the mess that 'unsilled' people make using complex tools. Tools such as databases (my area) are presented as being easy to use by microsoft, who make a lot of effort to make it easy to use. Too easy. Not because I want to keep people out, far from it, but because if they don't know what they are doing they get only so far, then things go bad and they've no idea why. Drag/drop, point/click only goes so far.
I guess no complex tool can be (or should be?) used with concomitant levels of training. It's not an argument for code gurus to make themselves a comfortable walled garden to preside over and keep others out, it's an argument that tools should come with training, always.
The problem these days is the hirers just want everything (blah blah full stack blah) and don't understand the cost of getting it wrong because it works - up to a point. MSSQL, Spark, Kafka, down to failure to understand how CPUs work. They all get treated as black boxes, and that's fine up to a point. Then things break or don't scale. Out of my sphere I see so many websites that have no basic understanding of usability, or standards, or accessibility, security and by web devs that barely understand HTTP.
If it's plain line of business, unimaginative gruntwork that keeps a business alive with spreadsheets etc, then that's what's needed and basic understanding is sufficient. I've done plenty of jobs like that, they keep the economy going, but if you want heftier dev work, I don't think that will suffice.
I guess that makes me sound a snob. Not intended that way, just saying complex tools may not be usable to their full capacity without understanding them. I may be wrong too.
But... so am I. The gap between us is education. What I propose is that one could take a class to learn how to make apps, as oppose to a CS class. I don't think a GUI app maker is the right approach to lowering the bar to custom apps. I think learning how to use API's is.
HTML is a great way to start. Then CSS. Then basic Javascript. From there you start bringing in tools like Bootstrap, jQuery, and PouchDB.js. From there you teach how to integrate most any JS toolset, like Mustache.js and Accounting.js. At that point things like React and Angular are already accessible.
When you focus on the tools and techniques to build apps it becomes more accessible and, yes, there will be some really crappy apps made, but there will also be those who do it very well.
Now... if you add into that mix turnkey opensource apps that already do something well that anyone can twiddle with it can really make a difference for all kinds of businesses.
Big businesses already have access to that kind of specialization of software but we're close right now to being able to lower the bar for medium and even small businesses to have affordable access to tailored apps. Local shops that make websites could offer those services to local businesses.
So I see it as a way to raise all the boats in the waters. But yeah, there will some trash and flotsam there too. Same as it ever was really. Just lowering the bar of entry.
I don't know, if a system exposed a EAVT database like Datomic where you don't need to normalise tables and you don't have to index manually and the n query problem isn't an issue then I think a non expert could get a lot further with the right UI then someone given a traditional SQL/NoSQL database
It's easy to make things complex and its hard to make things simple but if we can simplify to a data model then we can do declarative programming and make systems more tenable
Thinking in declarative data models is hard if you're not used to doing it, I'd recommend looking at the following libraries in Clojure: Garden, Hiccup, HoneySQL or Drupal's form management, or kind of ReactJS if you stretch your idea is what data is, they can all handle complex but focused tasks
I have to be sceptical about what you say, so understand that comes from lack of knowledge of what you're getting at (but I do know my SQL very well, and I do know declarative programming, of which SQL is an instance)
> EAVT database like Datomic where you don't need to normalise tables
That is a strange comment to me. Normalisation is not about databases but about data management. The value of normalisation doesn't go away just because you're using a different DB, because it's solely about relationships in the data.
> and you don't have to index manually
Woo, don't know what to say to that. Could you provide some pointers to both of these (normalisation and indexing) and I'll do some reading, thanks. I find that very hard to believe (no offence!)
Agreed about the 'hard to make things simple' but
> if we can simplify to a data model then we can do declarative programming
That data model is arguably normalisation. SQL is declarative, and I've seen the results of ignorance applied to that, so I can't buy that just using SQL protects you much (although it does to an extent, I suppose).
Declarativeness makes things easier on the programmer up to a point. When things break, there's not much you can do - and things can break easily in SQL. Writing good SQL, like any program, takes skill.
Also I recall many years ago finding out the hard way that you have to understand prolog's (relatively simple) search strategy to get decent results from it. Just 'declaring' your relationship between input and output didn't work at all well (I don't remember the details but I remember the lesson I learned).
And its sort of an insult to training, since there is very little actual formal training. Over 95% of the processes I use in developing software and systems are ones I've learned on the job, not learned while learning to be on the job.
An apprentice system would work extremely well with software development.
I learned to develop software [1] before the interwebs, where we would just kind-of hack things together in C/Unix. Manuals were our only (& best!) friend.
I then went to uni for a CS degree, and they had a very "holy grail" attitude about the whole affair.
I agree that:
1) an apprentice system would work better
2) we have got to get more powerful tooling out there, into people's hands
[2] I'm still reminded of a world where the bridge between creating & using software was much smaller (not to mention, user interfaces were much snappier!) Here's a virtual toast to hoping we can one day come back to that reality.
I'd agree with this, but I'll also mention that my undergrad degree was actually phenomenally helpful. One or two classes were legitimately beneficial for what they said on the tin (i.e., taught me useful concepts more quickly than I could have learned them on my own, or taught me concepts I never knew I needed, such as agile methodologies), and the rest presented problems in a space I could comparatively safely 'fail' in, that I had to figure out how to solve on my own, both technical and people based ones.
But that said, I also recognize that that may be the exception, and that on the job I might have learned the same things in less time.
That's a pretty sweet looking tool set you've put together. That looks like something small businesses would love have someone onboard that knows how to use it.
I'm not a spreadsheet power user. I've not really done much at all with them, but I'd love to tinker with Mintdata!
Jokes aside, imagine if Annie in accounting has the ability to define her own malleable tools, on top of a solid/robust system for centrally managing data? (version, backup, secure via IAM, etc)
Or will we really be stuck writing procedural code for the next 20, 30, 50 years?
--
[1] Caveat: chief hillbilly of https://mintdata.com here, where we think you really can have your cake (create expressive tools) and eat it too (centrally control, manage, and version your data)
.
Sure, but that's not "modifying the original system" any more. That's taking the original system (original abstraction) as a fixed/static foundation, and then expressing things in terms of it.
Which, I mean, if the tooling you've made is Turing-complete (Excel, Unix) then you can certainly say that the person working on top of your system is "programming"; but they're not programming your system. They're not writing plugins that interface with it on the same terms that its components interface with one-another (as you would be if you e.g. wrote your own POSIX shell utilities in C); they're trapped "above" that abstraction, in a sandbox, one from which they can only access the narrow subset of the API surface that you explicitly chose to expose to them.
Let me put it this way: you can get pretty far using e.g. Postgres as a custom data platform, by defining custom functions and types. But at some point, you'll need to write a Postgres extension. There's a big difference between a system that makes it easy for someone who's not a professional programmer to work on top of it (PG functions/types) and a system that makes it easy for someone who's not a professional programmer to extend it (PG extensions.) I've not yet seen a constructive proof that the latter is even possible.
I'll give you an example that mid-way [1] disproves the above.
Think of a typical "product tour" in a SaaS product. We're building the MintData product tour, in MintData itself. We then "publish" this "product tour application", and include it with the original blank design that a user gets when they first enter MintData.
So, in a way, our MintData onboarding is built in/on MintData itself, a bit like how you can have a bootstrapping compiler (one that compiles itself).
So, is the above us "modifying the original system"?
I think to some extent yes, although we have special spreadsheet functions that help jump the gap between Onboarding Application and Blank User Design (akin to the Postgres extensions [2] above).
So I think it is possible to build a system that allows you to then customize the system's own behavior (earlier versions of MintData could not build the onboarding experience, similarly to how the first compiler has to be built in a lower level language).
Genuinely curious -- derefr, do you agree or disagree with the above?
[2] As a person who was held at Grade-point and forced to write PostgreSQL C code to "modify the original [Postgres] system", I can only say it's an acquired taste :) Even Prof Franklin at UC Berkeley I think would back me up on this :D :D
Bootstrapping means only one thing: The entirety of a system is implemented within itself. This feat is binary: Only 100% means anything.
Your example is also very clearly not related in any way to "modifying the original system". Instead, it just means that you yourself have used project A (MintData) as a customer to make a distinct project B (an onboarding system that happens to be for MintData itself).
Modification is not assembling provided building blocks. Rather, it is changing the building blocks themselves. Say, you provide a HTTP JSON API, and I want to add support for websockets. Maybe I want to add entirely new data ingress/egress facilities. Or perhaps add a JavaScript interpreter to the backend to allow for rules and cron jobs written in JavaScript.
In your case, I see an ERP system which can be configured by users to do various things. From the perspective of the user, the original system is immutable, and they are no more able to change your product as a user than they are able to change Squarespace, GitHub, or for that matter Netflix and Spotify.
If you have navigated PostgreSQL C, you must surely understand the difference between configuration and modification.
---
General marketing trick: Use the product name less. It makes it stand out more to put it in one, well-placed spot. Use it too much (like above), and it instead becomes noise.
I think I get what you're talking about. Some systems are designed in such a way where the "platform" is formed in two layers: a low level, which exposes a set of primitives; and then a set of abstracting core libraries, implemented in terms of those primitives. Users are expected, idiomatically, to create business logic by making calls into the core libraries; but they're also free to call on the low-level primitives directly. In such a system, the "userland" sits directly on the primitives, with the core libraries as a sibling.
This is the pattern adopted by some, but not all, "runtimes." For example, Erlang has the low-level BEAM VM, and then has the Erlang "kernel" implemented as BEAM bytecode, rather than as native emulator support code. For another example, MOOs (object-oriented MUDs, e.g. LambdaMOO) only had the barest object-graph infrastructure specified in native code; everything else about the foundations of a MOO was defined in terms of objects and classes held in the MOO's state database.
In such systems, you have a sort of "intermediate" level of access to the native API surface, greater than the kind you have from the userland of a traditional VM or OS kernel.
Still, this "intermediate" level of access still doesn't allow you to break through the abstraction layer that the low-level primitives are founded upon. If there are any "complex" primitives implemented entirely natively (e.g. Erlang's `term_to_binary` function), then you can't "break into" that primitive to extend it unless the native runtime has been extended with an explicit "upcall" hook back into the VM userland.
You've linked to your site on at least 4 comments in this thread, which is really taking away from the comment experience. I am glad you're enthusiastic, but make sure the disclaimers don't take away from your (otherwise great!) comments.
I think we have 2 options:
OPTION 1)
We've reached a plateau -- software will continue to be developed as it is now, no new abstractions.
OPTION 2)
Mankind will create a better set of tools to:
- reduce the effort needed
- increase the # of people who can participate
in the translation of ideas/requirements -> software.
For everyone's sake [1], I really hope it's the second! :)
As one crazy idea, imagine if you could have a spreadsheet that would let you build software instead of crunch numbers... ... anyway, probably a bad idea, we should stick to our current abstractions and tools :D
[1] Take the above with 2.42 lbs of salt, I'm the founder of
https://mintdata.com