This is basically what Go PenPoint programming was like. When you read the Go documentation it’s very clear they intended to use Objective-C or an equivalent preprocessor; I suspect they were stymied by NeXT’s acquisition or Stepstone and their own lack of support for GNU C.
C-Macs – a pure C macOS application
131–138 of 138 posts
Re: C-Macs – a pure C macOS application
#132Uses under 1.5 MB of memory at any one time (most of it is used for drawing the window). Unfortunately there is no screenshot and I have no access to a Mac at the moment, but if View.c is where things actually happen, that is a huge amount of memory just for a (resizeable?) window with a little filled rectangle in it. The memory usage of a trivial app like this should be measured in kilobytes. Comparing applications…
It also depends on how the operating system and frameworks actually work. For instance, the backing store for the window may be “charged to” the application on macOS but may be provided by the OS on another platform, or there may not even be one.
Re: C-Macs – a pure C macOS application
#133Earlier quoted context omitted.
> Sloppiness /is/ Unix design, that's intentional. It's called "worse is better". That's missing the point. It's about simplicity through well designed abstraction. Unix was a runaway game engine that became Bell Lab's standard for talking to computers because it was vastly simpler than the poorly engineered MULTICS and friends. That's why it won. > On the other hand, nobody uses Plan9 I use Plan 9 every day. I'm rep…
Hyperbole; "nobody" means an insignificant amount of people.
Go programmers use something Plan9-y, but I don't think much of Go's design either; it's a combination of Unix's underdesign with Plan9's inflexible and idiosyncratic taste.
Re: C-Macs – a pure C macOS application
#134Earlier quoted context omitted.
Even then, MFC and C++/CX were the only productive ways to use it from Microsoft SDKs. .NET isn't as convenient as VB 6 was, fully embracing COM as the VBX replacement model, technically introduced in VB5, but still some stuff was lacking. Then there is Delphi and C++ Builder. It beat me that having doubled down on COM since how Longhorn went down, and Windows team getting their way doing avoiding .NET to take over,…
MFC's only COM support was support for ActiveX controls; it otherwise didn't do anything to help you with COM interaction. You may be thinking of ATL, which was specifically intended to help with COM. Source: worked professionally for years on an MFC-based app that communicated with an out-of-process COM server which we also wrote. The COM bits sucked.
ActiveX is just a brand name for a set of COM interfaces.
Just like nowadays WinRT is just having IInspectable alongside IUnknown, shipping .NET metadata file instead of a TLB and having an application identity.
MFC can pretty well do regular COM, and those macros are much developer friendly than the ATL template junk with multiple inheritance and IDL files without any kind of Visual Studio editing tooling support.
COM sucks no matter what when using Microsoft tools, for whatever reason Microsoft isn't able to deliver as good development experience for COM, as third parties, even though they push it everywhere.
For decades I expected them to finally catch up to Borland or Qt, C++/CX seemed to finally be it, but no, the "ATL rulez!" folks in Redmond had their way.
Re: C-Macs – a pure C macOS application
#135Earlier quoted context omitted.
1 is really trivial and took me like 5 seconds to write: public class Test { public static void main(String[] args) { System.in.transferTo(System.out); } } 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. Never versions of Java are quite pleasant to work with. There are a lots of quality-of-life improvements (switch expression, multi-line st…
> System.in.transferTo(System.out); Ok, that's really convenient :) I suppose it would be much harder to do it without the transferTo function, but that would be beyond the point. I'll instead focus on the example 2. > 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. The gRPC protocol here is only an example. Feel free to use any protocol yo…
So this is a direct reimplementation of your example in Java - https://gist.github.com/netvl/32698cc97b88267fecee9b30f00d16...
It is under 120 lines, uses Java SE API only, and the complexity is approximately the same. Go does have advantage of built-in selects and channels, which make parts of the logic nicer, but not by much IMO.
On the other hand, in Java almost no one uses standard library to write network apps like this. If I had to use external libraries, which would be the case in the majority of real-world projects, the implementation would look even better and clearer.
Re: C-Macs – a pure C macOS application
#136Earlier quoted context omitted.
> System.in.transferTo(System.out); Ok, that's really convenient :) I suppose it would be much harder to do it without the transferTo function, but that would be beyond the point. I'll instead focus on the example 2. > 2 is anything but trivial in any language, unless it is some kind of a language specifically designed to build gRPC programs. The gRPC protocol here is only an example. Feel free to use any protocol yo…
So this is a direct reimplementation of your example in Java - https://gist.github.com/netvl/32698cc97b88267fecee9b30f00d16... It is under 120 lines, uses Java SE API only, and the complexity is approximately the same. Go does have advantage of built-in selects and channels, which make parts of the logic nicer, but not by much IMO. On the other hand, in Java almost no one uses standard library to write network apps l…
That's impressive. However, even the direct reimplementation has introduced a subtle bug - a connection that sends something other than "server" or "client" is left hanging and never closed (use nc with -N flag, and press Ctrl+D to send EOF to see what I mean - it should disconnect and yet it doesn't). While not a functional bug, it could still cause a DoS attack if someone wanted to hog all the available sockets.
In Go, this is avoided by `defer conn.Close()` which guarantees that the connection will be closed at the end of the function execution, no matter what. It's a sort-of nicer syntax of "try {} finally {}" that let's you write the cleanup code immediately after the setup code, instead of at the end.
> On the other hand, in Java almost no one uses standard library to write network apps like this
I'm curious about the way the average Java programmer would write such an application. Would you please write an example of such a program, using an external library that would make implementation both correct and easy to read?
Re: C-Macs – a pure C macOS application
#137Earlier quoted context omitted.
So this is a direct reimplementation of your example in Java - https://gist.github.com/netvl/32698cc97b88267fecee9b30f00d16... It is under 120 lines, uses Java SE API only, and the complexity is approximately the same. Go does have advantage of built-in selects and channels, which make parts of the logic nicer, but not by much IMO. On the other hand, in Java almost no one uses standard library to write network apps l…
That's impressive. However, even the direct reimplementation has introduced a subtle bug - a connection that sends something other than "server" or "client" is left hanging and never closed (use nc with -N flag, and press Ctrl+D to send EOF to see what I mean - it should disconnect and yet it doesn't). While not a functional bug, it could still cause a DoS attack if someone wanted to hog all the available sockets. In…
Use try-with-resources instead of try/finally.
Re: C-Macs – a pure C macOS application
#138Earlier quoted context omitted.
Oh no that won't fly at all. People around here really like "proper" licenses. And they'll tell you about it.
I'm not a lawyer but one would definitely let you know that at least in the US, software without a license is more dangerous than software with even a very restrictive one. Someone can come along and determine the license at any time. So there is good reason to point it out unless you crave legal jeopardy.
GNU/FSF's opinion on informal licenses (https://www.gnu.org/licenses/license-list.html#informal):
Informal license
An “informal license” means a statement such as “do whatever you like with this” or “you can redistribute this code and change it.”
In the United States, these licenses are supposed to be interpreted based on what the author seems to intend. So they probably mean what they appear to mean. That would make them non-copyleft free software licenses and compatible with the GNU GPL. However, an unlucky choice of wording could give it a different meaning.
However, many other countries have a more rigid approach to copyright licenses. There is no telling what courts in those countries might decide an informal statement means. Courts might even decide that it is not a license at all.
If you want your code to be free, don't invite gratuitous trouble for your users. Please choose and apply an established free software license. We offer recommendations that we suggest you follow.