Big list of webapps masquerading as native


  • area_can

    @magus said in Big list of webapps masquerading as native:

    That should be your last concern when developing an app

    as someone with only 800MB of free space left on my phone, no i would like it to be at least a third-last concern



  • @dkf said in Big list of webapps masquerading as native:

    @jaloopa said in Big list of webapps masquerading as native:

    He's not keen on any OO languages IIRC

    Not even CLOS?!?! :trophy:

    Oh, I don't actually have a problem with OOP, or even OOP languages, as such - I am quite fond of Python and what little I've seen of Ruby isn't bad, and I even have a certain fondness for Smalltalk even if I never really got a solid grip on it.

    But I tend to see OO as a tool in the toolbox, rather than an overarching paradigm. In the Lisp world, OO is just that - even in a Lisp-family language that has no standard OO support, adding it is still just bit of macrology (and even that isn't really needed except to add syntactic sugar on the closures).

    In fact, the biggest problem with OO in Scheme is the lack of consistency - with no standard model, everyone and their brother rolls their own and nothing interops worth a damn. It's not a real showstopper for Scheme, though, because it fits in with the two main things it is used for (language design research and teaching intro programming - hell, some second-semester courses have 'write an OOP extension' for their course term project), but it does make it hard to do much else in it.

    (Hysterical note: The original plan for Scheme was to experiment with how to efficiently implement the Actor model, which is the 'objects that really are separate' approach developed at MIT in the early 1970s. However, at one point the did a code review and realized that the way the did them, the code for actors and the code for closures were almost identical, so they had A Major Epiphany and re-focused on refining closures. In other words, they concluded that they didn't need to support OO directly, and decided to leave that as an exercise for the readers.)

    It's not a problem in some other Lisp family languages, though; Common Lisp has CLOS, and Clojure allows you to dip into the Java libraries when you need to. Racket supports most of R5RS Scheme, but adds its own OO libraries and other goodies on top of it.

    For others - LeLisp, T, Arc, PicoLisp (I think), NuLisp (again, not sure), Kern-L - it would be a nightmare for them, if it ever really came up, but... well, they just never generated enough interest for it to become an issue.

    My real problems with Java, and with a lot of other languages in general, is that they focus so heavily on syntax that they end up with fairly shallow semantics. This probably isn't the place to get into that, though.



  • @heterodox said in Big list of webapps masquerading as native:

    @scholrlea said in Big list of webapps masquerading as native:

    And besides, JavaScript? I would have thought that they would prefer just about anything to JavaScript, especially given the disaster that was JScript (IIRC, it was almost as bad for them as their "let's highjack Java and call it Visual J++" lunacy).

    What was the JScript disaster I'm apparently unaware of? I recall JScript just being JavaScript that had some extra objects when run in CScript or WScript. When I was writing such scripts ~13 years ago (for AD management tasks etc.) I eventually switched from VBScript to JScript because I liked the syntax better (I missed braces, etc.) and never had any problems with it.

    OK, my recollection may not be great, but this is how I remember things. It is important to note that most of this was in the period 1997-2001, which may be why you aren't familiar with it depending on when you got into things. The JScript you are familiar with is probably a version that came after, and out of, all of this.

    As an implementation of pre-standard JavaScript, JScript was middling-to-good and the performance was better than that of Netscape's own version.

    The extensions for server-side programing, while rough around the edges, weren't terrible, but (by design) they tended to make websites dependent on the whole 'classic ASP' model of server-side code. However, since there really weren't any alternatives aside from using the already-aging Common Gateway Interface, not many people cared.

    The disaster was in the client-side extensions, which were added solely as an 'embrace, extend, extinguish' ploy. They were aimed at getting web developers to use them, and then say to the viewers 'Best Viewed Under Internet Explorer', meaning that you needed IE to really access the sites at all. Now, Microsoft weren't the only ones doing this - Netscape had a similar tactics, and even used a similar 'Best Viewed in Netscape Navigator' icon - but Netscape was given more slack because, well, they came up with JavaScript in the first place. Part of the issue was that JS wasn't an open standard at the time - Microsoft was actually leasing the rights to implement the language initially (the same was true of their license from Sun for their Java implementation, Visual J++).

    Microsoft's intentions were pretty obvious, so Netscape objected to the extensions, and threatened legal action. At the same time, however, they were also adding new features to their own JavaScript implementation which weren't covered by the license (again, Sun did the same thing with Java, and MS understandably got cheesed off at them both for the double-standard).

    However, unlike with Sun and Java, the deciding factor for JS was the web developers - most of whom threw up their hands in disgust and simply stopped using the proprietary features. The whole 'Best Viewed in' thing became an industry joke, and Netscape, who were having trouble elsewhere and in no position to fight, just gave up and handed the language over to a standards committee to deal with.

    While Microsoft had members on said committee, the rest of the standards body basically told them to keep the extensions to the server-side versions, and not mess around with the document model. To back this up, the ECMA people basically said that any extensions MS added would get a corresponding, but incompatible, version in the standard, leaving Microsoft the ones out in the cold rather than everyone else. Redmond got the message and toed the line on client-side for the most part since.


  • Discourse touched me in a no-no place

    @scholrlea said in Big list of webapps masquerading as native:

    (again, Sun did the same thing with Java, and MS understandably got cheesed off at them both for the double-standard)

    IIRC, the core complaints there related to binding between C++ and Java, where the approach that MS wanted to take was quick but extremely bound to the way they did things in quite a lot of ways (i.e., it could not be ported to other platforms compatibly) so Sun really decided to blow very cold on it. There was a lot of shadow boxing going on before whole thing detonated at management level and triggered the lawsuit, and the two companies really did not trust each other very much. If there'd been more willingness on both sides to really understand the perspective of each other and work together, they might have been able to work their differences out, but the bleed through from the commercial competition elsewhere in each organisation caused too much hostility for that to be an option.

    I believe the learnings from the MS approach ended up getting folded into the CLR.


  • Discourse touched me in a no-no place

    @scholrlea said in Big list of webapps masquerading as native:

    Oh, I don't actually have a problem with OOP, or even OOP languages, as such - I am quite fond of Python and what little I've seen of Ruby isn't bad, and I even have a certain fondness for Smalltalk even if I never really got a solid grip on it.

    FWIW, the surface of Python and Ruby both look pretty decent, but they've got yawning pits of :wtf: beneath. Especially Ruby.



  • @dkf said in Big list of webapps masquerading as native:

    Sun really cared about embedded systems and big iron at this point

    Sun really cared about beating Microsoft at that point. Otherwise the project made exactly no sense for them as it was blowing out their big iron mainly.



  • @bulb I don't know if 'big iron' is quite the term you have in mind, but that's because I tend to associate the term with mainframes; I am guessing that what you are both thinking of is rack-mount blade server systems, a space Sun were indeed heavily invested in by that time. However, they didn't want SPARC hardware to be just for blades; they still wanted it on the desktops of students and researchers and as a high-end alternative to the PC. The whole move to blades was them trying to be 'realistic', but in a way that let them cling to past glories a little longer and maybe return to them someday.

    By 1997 it was obvious to them and everyone else that the time where it was possible to have a separate workstation market distinct from both PCs and HPC servers was at an end. Top-end stock PCs in the $2000-5000 range were outperforming mid-range workstations in the $5,000-$10,000 range (though at the time the workstations generally still had other advantages in such things as reliability). But they really didn't want to believe it, so they were struggling to keep their SPARC alive (pun intended) with things like 'netstations' (basically, another iteration of the 'dicklessdiskless workstation', with no more success than the previous tries at it) and blade servers while they tried to figure out how to keep their workstations relevant.

    As @bulb said, part of the goal of Java - aside from its planned niche of high-end embedded systems - was to loosen the coupling between software and hardware, to make it easier for people to switch to Sun's hardware. However, in 1992, the target wasn't Windows; it was competing workstations by DEC, SGI, and HP, and to a lesser extent, DEC's VAX minis and mainframes. While things had drastically changed in those five years, Sun was still mostly thinking in terms of competition that no longer existed, or at least no longer mattered.



  • @dkf said in Big list of webapps masquerading as native:

    @scholrlea said in Big list of webapps masquerading as native:

    Oh, I don't actually have a problem with OOP, or even OOP languages, as such - I am quite fond of Python and what little I've seen of Ruby isn't bad, and I even have a certain fondness for Smalltalk even if I never really got a solid grip on it.

    FWIW, the surface of Python and Ruby both look pretty decent, but they've got yawning pits of :wtf: beneath. Especially Ruby.

    I don't really know Ruby internals, but I have to agree that a lot of Python's internals are kludges - clever kludges, sometimes, but often really bizarre and ugly ones. Also, it's true that there are plenty of kludges in the libraries and other programmer-facing parts as well. OTOH, I would be hard pressed to think of a language where that wasn't true. In the end, Python fits the way my mind works pretty well, which I guess is what matters when it comes to preferences in languages.

    Mind you, just because I don't love Java doesn't mean I wouldn't work in it; once your in a job, you do what they ask you to, or you don't take the job. You might debate the topic with them, and recommend something else, but you rarely get to choose except by deciding whether to take the position or not. My problem with my last job was that they changed their minds after six months, and switched to doing everything on SnailFarts, a platform that made me want to claw my eyes out.


  • Discourse touched me in a no-no place

    @scholrlea said in Big list of webapps masquerading as native:

    I don't really know Ruby internals

    Think “lots of stuff that's clever in isolation but which really doesn't work well together”, with a side-dose of “why the fuck would you do that?!”. The language community also really seems to like monkeypatching core language objects; that's a recipe for timebombs in pretty much everyone's code, as you get people pushing in new incompatible monkeypatches into upstream packages, resulting in small wars over syntax hacks.

    I really don't want to dig deep into Ruby code; I've always found major nasties every time I've looked in the past, and they're almost always from a lack of integrative thinking on the part of developers.

    I have to agree that a lot of Python's internals are kludges - clever kludges, sometimes, but often really bizarre and ugly ones. Also, it's true that there are plenty of kludges in the libraries and other programmer-facing parts as well.

    The weird part of Python is that they totally kludged a core language feature, their class system. That's… a really odd piece of design, and the problems it causes pop up all over the place through all its libraries. The hacks just layer very deep indeed, but at least they manage to mostly work together.

    Also, their threading is famously terrible. That's shit that can't really be hidden.

    OTOH, I would be hard pressed to think of a language where that wasn't true.

    There's really not that much that is that way in C; the exactly limited ambition (to be a less awful layer directly on top of machine code with little abstraction) means it doesn't need too many kludges to achieve that. OTOH, it pretty much assumes that you're there to do things for yourself in the first place. There are plenty of who say “But it doesn't do this feature!” and the response is “Yep; it doesn't. It also lets you make your own.”

    There are a few other languages that manage to keep the hack level down. (e.g., I believe that Scheme is relatively good that way, for example, but I've not used it enough to say from experience.)



  • @magus said in Big list of webapps masquerading as native:

    @masonwheeler said in Big list of webapps masquerading as native:

    Xamarin?

    Everyone ignores it. There's clearly a good, working way to make apps work on all operating systems. People just ignore it. Back when it was expensive, that made sense. Not now though.

    That's not really cross-Platform UI. I would describe Xamarin as Mono + bindings for native Platform APIs + development tools.
    Xamarin.Forms is a cross-Platform UI solution but only targets mobile (unless things have changed in the meantime).
    You might use GTK# or Qt-whatever but that's not strictly Xamarin. To be fair, Xamarin Studio (Visual Studio for Mac) has GTK# support but it kind of sucked when I tried it.
    Also, Xamarin was already so-and-so when I started using it, but now that Microsoft has taken over, stuff breaks every release and I'm consequently wasting time trying to workaround and filing reports. So I wouldn't personally recomment it nowadays. Which is sad, because IMHO it's soo close to be the perfect solution for mobile at least.



  • @zmaster said in Big list of webapps masquerading as native:

    Xamarin as Mono.NET Core + bindings for native Platform APIs + development tools.

    Note that Xamarin has been acquired by Microsoft quite some time ago and they are really trying to make sure it works now. They also switched to rather sensible pricing model where you can start developing for free and only pay when/if the application you write actually starts making you money. Like most their development tools lately.



  • @bulb said in Big list of webapps masquerading as native:

    @zmaster said in Big list of webapps masquerading as native:

    Xamarin as Mono.NET Core + bindings for native Platform APIs + development tools.

    I know they’ve switched to the MS compiler (Roslyn), are you sure they’ve also switched runtime? I thought they were just progressively replacing part of the Mono source with the MS reference implementation.

    Note that Xamarin has been acquired by Microsoft quite some time ago and they are really trying to make sure it works now.

    Well, they sure are doing a bad job in my experience.
    Even worse, they’re adding more thing like Web/Cloud/thatsortofstuff development to VSmac and on last build I’ve even seen some IoT thing.
    You were offering a cross-platform mobile development tool. Get that damn thing working well before thinking about more stuff.

    They also switched to rather sensible pricing model where you can start developing for free and only pay when/if the application you write actually starts making you money. Like most their development tools lately.

    I’d say it depends. It’s generally better.
    A couple of considerations though:

    • if you make a free app you’re still supposed to get a VS license if you’re company makes money with something else
    • before you could buy once and keep using the product (without getting support and updates after the 1 year), now you have to keep renewing the license
      Not saying these are problems, just pointing out differences.

  • Impossible Mission - B

    @scholrlea said in Big list of webapps masquerading as native:

    (Hysterical note: The original plan for Scheme was to experiment with how to efficiently implement the Actor model, which is the 'objects that really are separate' approach developed at MIT in the early 1970s. However, at one point the did a code review and realized that the way the did them, the code for actors and the code for closures were almost identical, so they had A Major Epiphany and re-focused on refining closures.)

    This isn't particularly surprising.

    A closure is a function with state associated with it. If you have more than one closure inside the same function, they will be associated with the same state.

    An object is state data with functions associated with it. It can have more than one function associated with the same object.

    In other words, objects and closures are literally just two ways of looking at the same basic principle, differing only in whether your paradigm see the data or the functions as the most significant element. Most OO languages implement closures by having the compiler secretly transform the closure into an object, and CLOS implements objects in terms of closures.


  • Discourse touched me in a no-no place

    @masonwheeler said in Big list of webapps masquerading as native:

    A closure is a function with state associated with it.

    A key matter is whether the state is modifiable by the functions. If it is not, you've got a “closure-lite” but it is pretty easy to implement. Modifiable state makes things enormously more complex under the covers (and pretty much requires that you've got a garbage collector). It's also a way to really “leak” memory in absolutely crazy ways, as it is so easy to forget that your closures are holding references to large data structures that you thought were just temporaries…



  • @dkf said in Big list of webapps masquerading as native:

    The weird part of Python is that they totally kludged a core language feature, their class system.

    You got me curious now: what's so kludgy about python's class system? I've never looked at the implementation, but the in-python side has always seemed rather straight-forward and well-working to me.

    @dkf said in Big list of webapps masquerading as native:

    There's really not that much that is that way in C

    Well, I'd say that's just because there's not much of anything in C, so the kludges are just done directly in C code.


  • Discourse touched me in a no-no place

    @ixvedeusi said in Big list of webapps masquerading as native:

    what's so kludgy about python's class system?

    I've never looked at the implementation

    Sometimes the obvious thing to do is the obvious thing to do. ;)



  • @dkf said in Big list of webapps masquerading as native:

    Sometimes the obvious thing to do is the obvious thing to do.

    :( What are you trying to do, getting me do some actual research? Inconceivable!


  • Discourse touched me in a no-no place

    @ixvedeusi said in Big list of webapps masquerading as native:

    :( What are you trying to do, getting me do some actual research? Inconceivable!

    OK, there are some really subtle things wrong with classes and their definition schemes in Python. This wouldn't matter except the wrongness spreads out and infects all sorts of things. Examples:

    1. self is an explicit argument.
    2. Decorators on members of classes can't know what class they're decorating something for.
    3. @staticmethod vs @classmethod
    4. Take a peek at how Abstract Base Classes actually work sometime.

    There's probably more which I'm not thinking about right now, but a lot of it comes down to subtle issues in the binding order and the details of what is actually fundamental as opposed to what is merely stated to be such.



  • @dkf said in Big list of webapps masquerading as native:

    1. self is an explicit argument.

    I consider that a definitely good thing. The other newer languages do that too.

    1. Decorators on members of classes can't know what class they're decorating something for.

    You can do class-dependent decoration in the metaclass. But yes, those two mechanism don't play too well together.

    1. @staticmethod vs @classmethod

    Make sense IMO. There is a first-class something representing the class itself, so they are somewhat different.

    1. Take a peek at how Abstract Base Classes actually work sometime.

    Well, there is no easy way to enforce abstract, but that's the case of most dynamically typed languages; nothing really specific to Python.



  • @ixvedeusi said in Big list of webapps masquerading as native:

    You got me curious now: what's so kludgy about python's class system?

    Read this, but only after you've set your mental alarms to mute so you won't got deaf:

    The very first sentence after the title should by itself give you an idea (heck, even the title!):

    3.3.4. Customizing instance and subclass checks

    The following methods are used to override the default behavior of the isinstance() and issubclass() built-in functions.

    In particular, the metaclass abc.ABCMeta implements these methods in order to allow the addition of Abstract Base Classes (ABCs) as “virtual base classes” to any class or type (including built-in types), including other ABCs.

    class.__instancecheck__(self, instance)

       Return true if instance should be considered a (direct or indirect) instance of class. If defined, called to implement isinstance(instance, class).

    class.__subclasscheck__(self, subclass)

       Return true if subclass should be considered a (direct or indirect) subclass of class. If defined, called to implement issubclass(subclass, class).

    Note that these methods are looked up on the type (metaclass) of a class. They cannot be defined as class methods in the actual class. This is consistent with the lookup of special methods that are called on instances, only in this case the instance is itself a class.

    Source

    0_1508859307755_4596d2f6-259a-4f89-9afa-5dbc486454c6-python-magic-methods-everywhere.jpg



  • @dkf said in Big list of webapps masquerading as native:

    1. self is an explicit argument.

    I have to agree with @Bulb that this is a good thing.

    1. Decorators on members of classes can't know what class they're decorating something for.

    Not something that has ever been much of a problem to me, and seems consistent with the notion of function decorators. Use decorators to customize functions, metaclasses to customize classes.

    That said, a similar thing which always annoys me is that a descriptor's getter or setter can't know by which name it was accessed.

    1. @staticmethod vs @classmethod…

    In practice I just don't use @staticmethod, and I don't really see why it would be a problem that both exist; just take your pick.

    1. Take a peek at how Abstract Base Classes actually work sometime.

    Now that made me go :wtf: when I first read about it, I perfectly agree on that one. It's true that the notion of "abstract base class" dos not really fit into the language's object model. Still, in practice I don't think I have ever encountered actual problems due to this.



  • @zecc said in Big list of webapps masquerading as native:

    Read this, but only after you've set your mental alarms to mute so you won't got deaf:
    The very first sentence after the title should by itself give you an idea (heck, even the title!):

    3.3.4. Customizing instance and subclass checks

    I know what you mean, but I'm sorry I have to profoundly disagree on that one. This is IMHO one of the very big strengths of Python: all the core language mechanisms are open, documented and accessible. You can customize anything, if you actually need to do so in order to get a natural and consistent API.

    Of course this can be abused. With great power comes great responsibility, and any such thing should be thought about long and hard before resorting to it; but I know that I can do it if I need to. In a way it's an extreme kind of operator overloading, which I consider an essential feature for any language: it can be a horrible mess if done wrong, but correctly applied it can make code so much more readable and understandable.



  • @ixvedeusi said in Big list of webapps masquerading as native:

    Now that made me go :wtf: when I first read about it, I perfectly agree on that one. It's true that the notion of "abstract base class" dos not really fit into the language's object model.

    I would say that the only :wtf: is calling them “abstract base classes” when they have nothing to do with those, because they are not base classes in the first place. They are rather concept checks, concept being an interface implied by the set of provided methods.



  • @bulb said in Big list of webapps masquerading as native:

    I would say that the only is calling them “abstract base classes” when they have nothing to do with those, because they are not base classes in the first place. They are rather concept checks, concept being an interface implied by the set of provided methods.

    I'd never seen python ABC's before, but reading that I just though - oh, they've bolted on an implementation of C++ concepts. There's literally no WTF here, unless you're so wedded to another languages implementation, that odd things like magic (i.e. conventional) double_underscore functions give you the willies.

    Given that Python was never the kind of BDSM language that flags up misuse, this strikes me as a reasonably sane way to go about it, especially if you document it well.



  • @gwowen said in Big list of webapps masquerading as native:

    There's literally no WTF here

    I insist that calling it “abstract base classes” is a WTF. But beyond that I agree it's sensible.



  • @bulb said in Big list of webapps masquerading as native:

    I insist that calling it “abstract base classes” is a WTF. But beyond that I agree it's sensible.

    I agree. The name would make sense, were it not already in use for a confusingly-similar-but-not-the-same thing elsewhere. Nice idea though, to separate ImplementsInterfaceOf from IsDerivedClassOf.



  • @gwowen Yes. The idea was kinda there in Python from the start as it always said to use “duck” typing meaning precisely that function accept objects as long as they provide appropriate methods no matter what they are actually derived from. This is just a formalization of that concept. Perhaps they should have added a special function quacks_like for it :-).


  • Discourse touched me in a no-no place

    @bulb said in Big list of webapps masquerading as native:

    The idea was kinda there in Python from the start as it always said to use “duck” typing meaning precisely that function accept objects as long as they provide appropriate methods no matter what they are actually derived from.

    That's fine until you get into the more complex protocols that objects can participate in. At that point, it becomes easier to have a way to flag that the object really is volunteering to participate in the dance. (Yes, you could do duck typing of an “I volunteer” method, but that's ugly.)

    I'm less bothered by enforcing that objects have to implement all the methods.



  • @bulb said in Big list of webapps masquerading as native:

    @gwowen Yes. The idea was kinda there in Python from the start as it always said to use “duck” typing meaning precisely that function accept objects as long as they provide appropriate methods no matter what they are actually derived from. This is just a formalization of that concept. Perhaps they should have added a special function quacks_like for it :-).

    Duck typing has its share of issues, though, mostly centred around the definition of "appropriate". Sure, my class has a method whose name is the one being called, and sure, it even has the right number of parameters / formal parameters / whatever you want to call them so that the call doesn't fail because the caller gave some other number of arguments / actual parameters / whatever you want to call them. For "duck typing" purposes, that's all that's required for it to be "appropriate". But does it do what the caller expects? What if the name is ambiguous in human-language terms, and both interpretations are reasonable and appropriate in the right circumstances?

    If my object implements a C++/C♭/Java-style interface (OK, yes, data-free all-pure-virtual base class in C++), then I can't pass the object to a function that expects the other interface.

    Well, unless I have implemented / derived from both interfaces, then I'm screwed if the calling signature of both functions (IFrist::method and ISnecod::method) is the same, since CMyScrewedClass::method overrides both of them.

    There's no easy solution that solves all cases, although some kind of annotation that tells which I'm overriding would help (then I write CMyScrewedClass::IFrist::method and CMyScrewedClass::ISnecod::method, problem solved). But that's Ugh Lee.



  • @steve_the_cynic said in Big list of webapps masquerading as native:

    C♭

    is there such a thing?



  • @steve_the_cynic I like the idea that "ABC"s implement optional-strong-typing. Weak typing is convenient, but has safety draw backs - anything can walk(), quack() and fly() but that don't make it a duck, just a superficially-duck-like object.

    With ABCs you can introspect an object and say "do you solemnly swear on pain of death that you are actually a Duck?" That's handy, even if the magic double_underscore methods look like an abstraction leak. That's a real failing of python - since the abstractions are all bolt-ons, they tend to be leakier than the Titanic.



  • @marczellm There is a Cω at least. Although I would guess an Accalia is responsible for it being flat rather than sharp in this case, as I've not heard of it either.



  • @atazhaia said in Big list of webapps masquerading as native:

    an Accalia

    I hate when I accidentally type ♭ instead of ♯.



  • @dkf said in Big list of webapps masquerading as native:

    @bulb said in Big list of webapps masquerading as native:

    The idea was kinda there in Python from the start as it always said to use “duck” typing meaning precisely that function accept objects as long as they provide appropriate methods no matter what they are actually derived from.

    That's fine until you get into the more complex protocols that objects can participate in. At that point, it becomes easier to have a way to flag that the object really is volunteering to participate in the dance.

    Yes. And that's exactly what the inappropriately named “abstract base classes” provide (you can use them to check existence of members, explicitly marking types, or mixture of both).

    @steve_the_cynic said in Big list of webapps masquerading as native:

    Duck typing has its share of issues, though, mostly centred around the definition of "appropriate".

    Yes, it does. And it reduces the manipulexity, which is a price to pay for the improved whipuputitude. It's a trade off that most dynamic languages including Python, and Go, chose to make.

    @steve_the_cynic said in Big list of webapps masquerading as native:

    If my object implements a C++/C♭/Java-style interface (OK, yes, data-free all-pure-virtual base class in C++), then I can't pass the object to a function that expects the other interface.

    Yes. But it often means you have to create adapters simply because the author of the class didn't think to implement the interface even though they actually did. Or couldn't implement it, because the interface is defined at higher level than the type.

    @steve_the_cynic said in Big list of webapps masquerading as native:

    Well, unless I have implemented / derived from both interfaces, then I'm screwed if the calling signature of both functions (IFrist::method and ISnecod::method) is the same, since CMyScrewedClass::method overrides both of them.
    There's no easy solution that solves all cases, although some kind of annotation that tells which I'm overriding would help (then I write CMyScrewedClass::IFrist::method and CMyScrewedClass::ISnecod::method, problem solved). But that's Ugh Lee.

    IIRC C# and Java do actually allow that.

    The best approach seems to be type classes, also known as traits. You can define them for existing types and since the definition block states both the class and the type, there is no ambiguity.



  • @marczellm said in Big list of webapps masquerading as native:

    @steve_the_cynic said in Big list of webapps masquerading as native:

    C♭

    is there such a thing?

    There is. It is also called "a joke" or "I was having fun at Microsoft's expense". What was sad is that it took me several minutes to find my system's equivalent of charmap. (It's a long story(1) that I strongly advise you all not to try to emulate. Really.)

    (1) It involves FreeBSD, upgrades, a Gnome2 to Gnome3 translation discarded in favour of Mate, several bits of KDE, and a lot of pain. But in my opinion, it's less painful than the alternative. But it's for $job. At $home, no way I'd touch any of it.



  • @steve_the_cynic said in Big list of webapps masquerading as native:

    my system's equivalent of charmap

    I recommend installing this command-line utility for querying the Unicode database (obviously also here, upstream here).



  • @steve_the_cynic said in Big list of webapps masquerading as native:

    But in my opinion, it's less painful than the alternative.

    Less painful than googling "unicode flat" and copying the result from the 4th or so result?



  • @marczellm said in Big list of webapps masquerading as native:

    @steve_the_cynic said in Big list of webapps masquerading as native:

    C♭

    is there such a thing?

    Yes, but its enharmonically equivalent to B, the forerunner of C.



  • @gwowen said in Big list of webapps masquerading as native:

    @marczellm said in Big list of webapps masquerading as native:

    @steve_the_cynic said in Big list of webapps masquerading as native:

    C♭

    is there such a thing?

    Yes, but its enharmonically equivalent to B, the forerunner of C.

    except in Hungary, where B is localized to H or Italy/France/Spain... where it is Si



  • @marczellm said in Big list of webapps masquerading as native:

    where it is Si

    So do they code in Si♯?


  • Notification Spam Recipient

    @bulb said in Big list of webapps masquerading as native:

    Yes, it does. And it reduces the manipulexity, which is a price to pay for the improved whipuputitude. It's a trade off that most dynamic languages including Python, and Go, chose to make.

    Boo.



  • @marczellm said in Big list of webapps masquerading as native:

    except in Hungary, where B is localized to H or Italy/France/Spain... where it is Si

    But will a Spanish-speaking musician understand which note you're referring to when you say "B"?

    Si.


  • Notification Spam Recipient

    @zecc said in Big list of webapps masquerading as native:

    @marczellm said in Big list of webapps masquerading as native:

    except in Hungary, where B is localized to H or Italy/France/Spain... where it is Si

    But will a Spanish-speaking musician understand which note you're referring to when you say "B"?

    Si.

    Well, since "c" is pronounced how you would say "seh" in English, yes.



  • @bulb said in Big list of webapps masquerading as native:

    @steve_the_cynic said in Big list of webapps masquerading as native:

    my system's equivalent of charmap

    I recommend installing this command-line utility for querying the Unicode database (obviously also here, upstream here).

    On FreeBSD 10.3:

    # pkg install unicode
    Updating FreeBSD repository catalogue...
    Fetching meta.txz: 100% 940 B 0.9kB/s 00:01
    Fetching packagesite.txz: 100% 6 MiB 6.1MB/s 00:01
    Processing entries: 100%
    FreeBSD repository update completed. 26953 packages processed.
    All repositories are up to date.
    pkg: No packages available to install matching 'unicode' have been found in the repositories

    Not in the Ports Collection either.



  • @zecc said in Big list of webapps masquerading as native:

    @steve_the_cynic said in Big list of webapps masquerading as native:

    But in my opinion, it's less painful than the alternative.

    Less painful than googling "unicode flat" and copying the result from the 4th or so result?

    No, I meant less painful than the various suggested alternative work environments here. The :wtf: is fairly strong here.



  • @steve_the_cynic It's a single Python script and a couple of data files. Just download it from the upstream.



  • @bulb said in Big list of webapps masquerading as native:

    @steve_the_cynic It's a single Python script and a couple of data files. Just download it from the upstream.

    Yeah, I saw that, but... I don't want a Unicode lookup tool. I want an equivalent of charmap that I can use to look at characters and compose things and copypaste them elsewhere.

    And the complaint was more directed at the disconnect between "I use FreeBSD" and "Install this Linux package".


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.