Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Obvious and possible software innovations

scottlocklin.wordpress.com

Post reply on HN
Print view View original

111–120 of 157 posts

Re: Obvious and possible software innovations

#111

Post by clarge1120 »

Santosh83 wrote: post #51

> Engineers are a defeated tribe; it’s cheaper to hire an “AI” (Alien or Immigrant) slave to write the terraform or electron front end rather than paying clever engineers well enough to build themselves useful tooling to make them more productive and the world a better place. Offensive passage that subtly implies immigrants from the developing world are slavish (and dehumanising them as well, using the word alien), i…

There is no racism here, subtle or otherwise, and I say this as a black engineer watching this happen every single day. Engineers are not allowed to talk about how their jobs are being replaced by web development in every possible corner even where it doesn’t fit.

It is much cheaper to hire 5 offshore web devs for 5 weeks to force a solution into a web interface and then have an onshore dev spend 2 weeks turning web UI into an Electron app than it is to build any other type of solution.

He is simply stating the issue rather than not stating it.

Re: Obvious and possible software innovations

#112

Post by [deleted] »

l33t2328 wrote: post #82
kodablah wrote: post #10

> have all the functions described in it turned into reasonably safe FFIed function calls Many langs get close with the ease of importing C headers (Go, Rust, etc), but once you ask for reasonably safe FFI'd calls, you're asking a bit too much since ownership goes out the window. Otherwise, if you mean turned into acceptably-unsafe FFI'd function calls, agree just about every lang with C interfacing built in should h…

I’ve never heard of C function “ownership”. What does it mean?

[deleted]

Re: Obvious and possible software innovations

#113

Post by contextfree »

_ph_ wrote: post #77
RcouF1uZ4gsC wrote: post #14

> Automated FFI parsers. In 2021 I should be able to point any interpreted language at a C include file and have all the functions described in it turned into reasonably safe FFIed function calls, The big issue with doing this is that C does not have enough of a type system to exactly specify the interface. Is that char pointer, a null terminated string, or is it a pointer to an untyped buffer? What is the ownership…

I think this points to the real answer: libraries should be defined by something else than the C headers we are using now. All automated solutions or parsing C headers require a C compiler present and as you write, there is a lot left unspecified.

Windows has partly moved and is moving in this direction - WinRT (higher-level, C#-like but without requiring the .NET runtime and GC) APIs are already defined in metadata, and now Win32 (lower-level, C-style) APIs are being defined that way as well: https://github.com/microsoft/win32metadata/blob/master/docs/...

Re: Obvious and possible software innovations

#114

Post by smsm42 »

roca wrote: post #23

I only had to read the first few sentences of the first point to see that the author thinks problems are easy because they don't understand the difficulties. Parsing C function prototypes doesn't give you enough information to write safe language bindings. For example if you see "char* make_stuff(const char* param);", you don't know whether the memory pointed to by 'param' can be reused after the function call, or wh…

All those difficulties are real, and yet, FFI exists and is useful. Of course it won't work in 100% cases, but it would work in many cases, because all those things that you describe aren't random - usually libraries have certain conventions on what the pointers mean, who frees them, etc. What the author is asking for is extending the basic service FFI provides to make it more useable and accessible. Still wouldn't solve 100% of causes, and still the questions like "is it thread safe" would never be part of it - so what? There are many use cases which can live without answering this question.

Re: Obvious and possible software innovations

#115

Post by superdisk »

Aeolun wrote: post #96
japhib wrote: post #9

I actually really dislike this whole post. There’s a really condescending tone lurking just beneath the surface for most of it. It’s also extremely hand-wavy about the problems, their causes, AND possible solutions. Also, so whiny. At this point I don’t care if he even has any good ideas because he’s made me so mad just by his writing style.

I actually tried doing the native GUI thing, but I gave up when I found out I couldn’t do that without having to reimplement something as simple as an autocomplete dropdown. Yes, the native select has something like it, but it only reacts to typing the first characters, and you can’t style the results. I guess some would call this a feature, but the customizability of HTML makes for a lot of good things as well.

> You can't style the results

Good.

Re: Obvious and possible software innovations

#116

Post by aleclm »

At rev.ng we're developing ludwig, a clang-based automatic generator of wrappers for C++ APIs. First we generate C API and then generate wrappers for dynamic languages such as Python/Ruby/JS.

It's basically SWiG done right. Trying to write a C++ parser is a design doomed to fail.

In C++ ownership is much more explicit than C on average. The idea is to have a Python wrapping object for each C++ pointer. This wrapper can be owning or non-owning: if it's owning calls `delete` once the wrapper is destroyed. If a C++ function returns a std::unique_ptr we map it to an owning wrapper. If a C++ function returns an object by value we `std::move` it on a new object on the heap and map it to an owning pointer. If a C++ function returns naked pointers, we map it to a non-owning wrapper. The system is extensible, for instance you can say that a owner (see C++ Core Guidelines) is actually owning.

The wrapper can also be const or non-const, exposing the appropriate methods accordingly.

Also you have a lot of patterns you can exploit to provide high level constructs in scripting languages (e.g., `.begin` + `.end` ranges can become Python generators rather easily).

Here you can find the design document:

    https://pad.rev.ng/s/__WrFSmm_#
Right now, we're struggling with default template arguments. Many STL classes have default template arguments which make the name of types look ugly.

Also, we currently instantiate all the methods of template classes. But not all methods are supposed to be instantiate with all the possible template values. If you do instantiate those, you can run into compile errors. This means we have to resort to a sort trial and error approach to see what it actually makes sense to instantiate.

ludwig will be open source, but still needs some love before going public.

Re: Obvious and possible software innovations

#117

Post by clarge1120 »

Aeolun wrote: post #107

Every time I read something like this, I think how much I want a true cross platform GUI library with the customizability of HTML/CSS, determine to build it myself, then give up before I even start when I realize how much work it’s going to be.

Same here. A native cross-platform GUI library with HTML/CSS native markup would set the works aflame.

It would take many man-years to build, and would take the dedication of Torvolds and the core Linux team to bring into the world.

Re: Obvious and possible software innovations

#118

Post by bawolff »

TimTheTinker wrote: post #15
japhib wrote: post #9

I actually really dislike this whole post. There’s a really condescending tone lurking just beneath the surface for most of it. It’s also extremely hand-wavy about the problems, their causes, AND possible solutions. Also, so whiny. At this point I don’t care if he even has any good ideas because he’s made me so mad just by his writing style.

Perhaps he's a generation or two older, and doesn't want to go into a lot of technical detail to back up his opinion. I think his perspective is valuable. He's seen a lot, and he's right that we could do to learn a few things from the past.

What value is an opinion if you can't back it up?

Re: Obvious and possible software innovations

#119

Post by smsm42 »

jacobsenscott wrote: post #59
underwater wrote: post #8

Feels like a list of stuff where he massively underestimates the complexity of the fields he's talking about. Drag and drop UIs have, as he indentified, been tried. They were a leaky abstraction where incremental functionality was difficult to implement.

I've never seen a web UI that couldn't be built, and built better, in an hour with an old school drag and drop gui builder. Unfortunately the web was built on markup, and markup is a terrible way to define a UI. There is really no way to make a good gui builder for html/css, so we are stuck with literally the worst possible way to build UIs today. CSS is 24 years old, and nobody has figured out a sane way to use it y…

The whole HTML-ization of GUIs is crazy... It's like "ok, let's make a language that represents semantics of documents and leaves most of the presentation to the tools, so we could concentrate on content and not focus too much on irrelevant details of presentation" - "ok, cool idea, now let's take this language and use it to build pixel-precision GUIs that have no semantic content at all". Ugh, talk about right too for the job!

Re: Obvious and possible software innovations

#120

Post by rishav_sharan »

japhib wrote: post #9

I actually really dislike this whole post. There’s a really condescending tone lurking just beneath the surface for most of it. It’s also extremely hand-wavy about the problems, their causes, AND possible solutions. Also, so whiny. At this point I don’t care if he even has any good ideas because he’s made me so mad just by his writing style.

I started with some interest in this post but stopped reading when the author started saying nasty stuff about Bezos's wife. How is she remotely connected to this post? Why try to shame her for her looks or cosmetic choices?

The author is trying to hard to be edgy without being humourous or having the depth of idea that could have saved this.

Post reply on HN