As far as I can tell, this is only for the free personal plan, not any of the business offerings (ie not Copilot for M365) and Github Copilot is under a separate set of terms.
“These Terms don’t apply to Microsoft 365 Copilot apps or services unless that specific app or service says that these Terms apply.”
Think of Copilot being a suite of different products under the same overall banner and it starts to make (a bit) more sense.
Not really since the clause in full is
"Copilot is for entertainment purposes only. It can make mistakes, and it may not work as intended. Don’t rely on Copilot for important advice. Use Copilot at your own risk."
Are you saying that the business version cannot make mistakes and can be relied upon for important advice?
This is super interesting - aside from the benchmarks are there any good examples of loading and querying data from external sources? Any plans to support other formats like parquet?
So far, we haven't had any particular need for native support for parquet files. This type of import can be done satisfactorily via RayPy, and there is also a plugin that allows you to access kdb+ instances.
I hear you on the opportunity side and I can't see that changing. The good news is in recent releases there's a lot less boilerplate - "dotnet new console -lang F#" results in two files, a short fsproj file and a single line of Hello World.
This is an impressive achievement, given there’s a whole language plus IDE. Kudos to the author. I couldn’t see any indication of what the author plans to use it for - I hope he can share more below?
One of the most delightful places I’ve used Lua recently is in TurboLua, which gives the Lua VM access to all the necessary signals/pipes for writing high speed network applications, among other things. (https://turbo.readthedocs.io/en/latest/)
Do you see there being a way to make a TurboLuon with current specs?
What do you mean by "natively"? Ahead of time compiled, or just working? If the latter, the present VM is already available on the mentioned systems. In my version, Gingko, I additionally removed a lot of outdated code to increase platform independence.
nice! do you feel like oberon has something that gives it an edge over more currently popular languages, or is it just a matter of personal preference?
Actually, I only use original Oberon when I'm migrating the old Oberon systems. My interest lies in finding out how I would have to modify original Oberon to be as productive as I am used to with e.g. C++, but still adhering to the goal of simplicity. My version, which I call Oberon+ (and to which Luon is quite similar, whereas Luon is even simpler), goes in this direction.
Actually an "edge over more currently popular languages" from my humble point of view is the goal and maintenance of simplicity. The term is subjective, but if you look at many of today's completely overloaded languages, it is intuitive to understand.
I have to ask, "why?" in the spirit of if you're smart enough to write an Oberon on top of Lua and then use that to write a Smalltalk VM then you're certainly smart enough to get around a complicated language and tolerate a lack of some simplicity.
Probably a similar reason why equations are simplified in mathematics. If something is not represented or implemented as simply as possible, there is obviously overhead or redundancy. In the sense of the lean philosophy, that would be waste.
Simple solutions are also less prone to errors and easier to modify and expand. This reduces the probability of errors and makes it easier to maintain and update the system.
Simplicity makes systems (and programming languages) easier for users to understand and use. This leads to greater user-friendliness and reduces the learning curve, resulting in a more positive user experience and, in turn, a lower error rate.
I'm sure there are many more reasons (apart from the obvious proof by authority, which is based on the statements of, for example, Einstein or Wirth).
I get the appeal to write an IDE from scratch, especially if you are already an expert in writing GUIs with your framework of choice! I wonder if it would make more sense to spend that time writing a language server protocol daemon. That way, you could make your language available in any IDEs your users like that support LSP.
I'm usually working on older machines on which the IDE's supporting language servers would be much too slow or wouldn't work at all because of incompatibilities. I like lean tools with little dependencies. But there is a parser in moderate C++, so maybe someone else will implement such a daemon.
It's excellent hardware, I have many redundant copies and thus high availability, the system just works, I automatically take care of efficient implementation, and the generated executables have high probability to work on all newer Linux systems. And I'm too old to always chase for the new new version.
Optimizing your code for slow machines is a really great thing. I wish more people would do it. If your code runs well on a slow computer then it'll run well on anything better too. A lot of code these days only runs "well" on very fast computers...
I mainly develop TXR on a refurbished Intel box with a CPU that's like from around 2009 or something. It takes at least three times longer to rebuild everything than on modern machines. (It does have 32 gigs of RAM which is good for multiple virtual machines.) In fact I have one Dell box that was a server in a startup company that shut down in 2010. And that box builds the code significantly faster.
I am actually glad that this person developed the IDE. Please download the IDE and try it. It is exceptionally fast. When I compare the speed with that of IDEs like Visual Studio Code etc, the difference is night and day.
I would start with a business case - what are the benefits, is it going to generate revenue or reduce costs, when do the benefits start to be realised.
Then look at the cost in starting to develop what you need, and how you’re going to get started.
Are there existing COTS systems (e.g. SAP, Dynamics, Salesforce) that are extensible but can do 60% of the base functionality out of the box? Can you start by integrating two systems or using your low code platform to prove the concept? A couple of engineers/freelancers/external shop for a few months is a lot cheaper than hiring a whole development team… others in the thread have given you a reasonable estimate of that.
Think about what’s the MVP needed to start showing ROI. Maybe do a smaller business case for that.
Look at the payback period internally and ask what hurdle rate is needed to invest from your CFO.
FWIW, I started programming F# during your tenure at MS and in a couple of years it became a really capable cross platform option - partly MS, partly community, but definitely helped out by you. Thanks!
reply