12 ms·

Are all of those proprietary products? I can't speak on your experience, but if linux was created in 1991, seems like in another angle you're bemoaning the rise

by apsurd 3y ago

Are all of those proprietary products? I can't speak on your experience, but if linux was created in 1991, seems like in another angle you're bemoaning the rise of OSS and web. I'm just a web developer that learned everything from online resources. So i think we are both biased on different ends on the spectrum.

Throw10987 3y ago
I think the point is that the Access, Lotus Notes tooling was in largish corporations somewhat ubiquitous. The experience of this tooling was make a change and it was in production. It was incredibly simple and productive to work with given the needs of the time. There was also plenty of opportunities to make a mess, but I don't think that has really changed. Learning was not difficult, you just had to be prepared to spend time and some money on books and courses. It is not a tooling set you would want to go back to for a bunch of different reasons but it worked well for the time.
- josephg 3y ago
  > It is not a tooling set you would want to go back to for a bunch of different reasons but it worked well for the time. I remember using lotus domino at one of my first jobs. There were all sorts of things I hated about it. But you could have a database - like the company’s mail database. And define views on that database (eg looking at your inbox, or a single email). And the views would replicate to a copy of that database living on all of your users’ computers. And so would the data they needed access to. It was so great - like, instead of making a website, you just defined the view based on the data itself and the data replicated behind the scenes without you needing to write any code to make that happen. (At least that’s how I understood it. I was pretty junior at the time.) Programming for the web feels terrible in comparison. Every feature needs manual changes to the database. And the backend APIs. And the browser code. And and and. It’s a bad joke. Commodification has a problem that for awkward teenagers to make the same fries every day, we have to ossify the process of making fries. But making good software needs us to work at both the level of this specific feature and the level of wanting more velocity for the 10 other similar features we’re implementing. Balancing those needs is hard! And most people seem content to give up on making the tooling better, and end up using whatever libraries to build web apps. And the tools we have are worse in oh so many ways compared to lotus domino decades ago. I wonder what the original lotus notes designers think of web development. I think they’d hold it in very low regard.
mikewarot 3y ago
Open source is great, Lazarus does a pretty good job of replacing Delphi. Microsoft went insane with .NET so VB6 was killed in the process. Access automatically handled table relationships, building queries and seeing them as SQL, and the report engine was pretty good. Thanks to ODBC, you could use the same database across all of them, or hook up to a real SQL server when it came time to scale up. What's missing is the desktop and a stable GUI API these days. Windows apps from the 1990s still work, because they are distributed as binaries. Most source code from back then will not compile now because too many things have changed. I love Open Source, but it doesn't solve everything.
- msla 3y ago
  > Windows apps from the 1990s still work, because they are distributed as binaries. Only if you have the right libraries, and runtimes, and OS interfaces, and even if you have all that, oh no, it's a MIPS binary and you don't live in 1996! Any proprietary API exists precisely as long as the owner says it does. Open standards don't suffer from that malady.
  - mikewarot 3y ago
    >Only if you have the right libraries, and runtimes That generally only happens with .NET based programs in Windows systems. You always need some .NET v2,3,3.5,4,4.5, etc., runtime.
    - tmcdos 3y ago
      Totally agree. There is no backward compatibility with .NET runtime - if your application is built/linked to a given version, it won't work with any other version of .NET
      - neonsunset 3y ago
        That's simply not true. Newest .NET 8 does not need the assemblies you reference to target .NET 8 - as long as the TFM is any version of 'netstandardx.x', 'netcoreappx.x' or 'net5'+ it will work. You can even make proxy-projects that target netstandard2.0 but reference .NET Framework and with certain compat shims the code will just run on .NET 8 unless it relies on some breaking changes (which have mostly to do with platform-specific behavior, there have been no breaking changes for the language itself since I think C# 1 or 2? some odd 20 years ago). As for the runtime itself - the application can restrict itself from being run by a newer version of runtime but you can absolutely do so. The lightweight executable that just loads runtime and executes the startup assembly may complain but just try it - build a console app with 'net5.0' target and then run it with latest SDK with 'dotnet run mynet5app.dll' - it will work.

by apsurd 3y ago

Throw10987 3y ago

I think the point is that the Access, Lotus Notes tooling was in largish corporations somewhat ubiquitous. The experience of this tooling was make a change and it was in production. It was incredibly simple and productive to work with given the needs of the time. There was also plenty of opportunities to make a mess, but I don't think that has really changed. Learning was not difficult, you just had to be prepared to spend time and some money on books and courses. It is not a tooling set you would want to go back to for a bunch of different reasons but it worked well for the time.

josephg 3y ago
> It is not a tooling set you would want to go back to for a bunch of different reasons but it worked well for the time. I remember using lotus domino at one of my first jobs. There were all sorts of things I hated about it. But you could have a database - like the company’s mail database. And define views on that database (eg looking at your inbox, or a single email). And the views would replicate to a copy of that database living on all of your users’ computers. And so would the data they needed access to. It was so great - like, instead of making a website, you just defined the view based on the data itself and the data replicated behind the scenes without you needing to write any code to make that happen. (At least that’s how I understood it. I was pretty junior at the time.) Programming for the web feels terrible in comparison. Every feature needs manual changes to the database. And the backend APIs. And the browser code. And and and. It’s a bad joke. Commodification has a problem that for awkward teenagers to make the same fries every day, we have to ossify the process of making fries. But making good software needs us to work at both the level of this specific feature and the level of wanting more velocity for the 10 other similar features we’re implementing. Balancing those needs is hard! And most people seem content to give up on making the tooling better, and end up using whatever libraries to build web apps. And the tools we have are worse in oh so many ways compared to lotus domino decades ago. I wonder what the original lotus notes designers think of web development. I think they’d hold it in very low regard.

mikewarot 3y ago

Open source is great, Lazarus does a pretty good job of replacing Delphi. Microsoft went insane with .NET so VB6 was killed in the process. Access automatically handled table relationships, building queries and seeing them as SQL, and the report engine was pretty good. Thanks to ODBC, you could use the same database across all of them, or hook up to a real SQL server when it came time to scale up. What's missing is the desktop and a stable GUI API these days. Windows apps from the 1990s still work, because they are distributed as binaries. Most source code from back then will not compile now because too many things have changed. I love Open Source, but it doesn't solve everything.

msla 3y ago
> Windows apps from the 1990s still work, because they are distributed as binaries. Only if you have the right libraries, and runtimes, and OS interfaces, and even if you have all that, oh no, it's a MIPS binary and you don't live in 1996! Any proprietary API exists precisely as long as the owner says it does. Open standards don't suffer from that malady.
- mikewarot 3y ago
  >Only if you have the right libraries, and runtimes That generally only happens with .NET based programs in Windows systems. You always need some .NET v2,3,3.5,4,4.5, etc., runtime.
  - tmcdos 3y ago
    Totally agree. There is no backward compatibility with .NET runtime - if your application is built/linked to a given version, it won't work with any other version of .NET
    - neonsunset 3y ago
      That's simply not true. Newest .NET 8 does not need the assemblies you reference to target .NET 8 - as long as the TFM is any version of 'netstandardx.x', 'netcoreappx.x' or 'net5'+ it will work. You can even make proxy-projects that target netstandard2.0 but reference .NET Framework and with certain compat shims the code will just run on .NET 8 unless it relies on some breaking changes (which have mostly to do with platform-specific behavior, there have been no breaking changes for the language itself since I think C# 1 or 2? some odd 20 years ago). As for the runtime itself - the application can restrict itself from being run by a newer version of runtime but you can absolutely do so. The lightweight executable that just loads runtime and executes the startup assembly may complain but just try it - build a console app with 'net5.0' target and then run it with latest SDK with 'dotnet run mynet5app.dll' - it will work.